project_key: SOA When an external service is invoked, a Web Service dispatcher is created to represent the remote service, configured with the endpoint reference for that service - either explicitly provided (by prior assignment to the partner link) or by default from the external service's wsdl. If the endpoint reference for the partner link is subsequently changed, the new value is currently ignored, as it will simply use the existing Dispatcher. One possible solution to this problem would be to use the existing dispatcher, only if an explicit EPR is not provided? This way the single dispatcher per partner link will be reused in most cases, but just replaced on a per invocation based if the EPR has been explicitly defined. Generally the endpoint reference for a partner link will only be established prior to the partner links first use. So the only impact is where a BPEL process wants to modify the endpoint reference part way through a session (as done by the dynpartner quickstart). So this is probably a low priority?
Link: Added: This issue is related to RIFTSAW-458
Link: Added: This issue is related to SOA-3549
This issue has been fixed as part of https://bugzilla.redhat.com/show_bug.cgi?id=807577. The fix has been applied to the 2.3.x branch and will be in the next build.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Once WS Dispatch had been created for service, it was reused for subsequent requests Consequence: Regardless of whether a different endpoint reference was associated to a partner link, it would reuse the endpoint reference previously initialized Fix: The dispatcher is now created for each external invocation Result: If an endpoint reference is assigned to a partner link, then it will call that endpoint as expected
Confirmed that the dispatcher is re-created.
Hi Marek Tom C found a performance issue related to this fix, so I'm currently testing out a change that hopefully addresses that problem. Should I create a new bugzilla, or should we just set the status of this bugzilla to retest on the next build? Regards Gary
Hi Gary I think a new BZ will be me more appropriate sice the performance issue is another problem. Btw. could you email me your test process for this issue? I have some problems with mine :(. It's unable to retrieve the port for the assigned service reference. Thanks. Best regards Marek
Hi Marek I'm testing in riftsaw (dynpartner quickstart with modified xalan.jar). The problem you are facing is probably the same as with bug 807577, which is awaiting an EAP patch that includes https://issues.jboss.org/browse/JBWS-2937 as far as I am aware. Jim Ma was also going to investigate why cxf was also having problems, but not sure how that is going. Regards Gary
Thanks for helping us by writing the draft release note, Gary. Much appreciated.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -Cause: Once WS Dispatch had been created for service, it was reused for subsequent requests +Once the WS Dispatch had been created for a service, it is reused for subsequent requests. However, even if a different endpoint reference was associated with a partner link, the endpoint reference previously initialized would be reused. In order to fix this issue, the software has been modified so that the dispatcher is now created for each external invocation. As a result, if an endpoint reference is assigned to a partner link, then it will now call that endpoint as expected.-Consequence: Regardless of whether a different endpoint reference was associated to a partner link, it would reuse the endpoint reference previously initialized -Fix: The dispatcher is now created for each external invocation -Result: If an endpoint reference is assigned to a partner link, then it will call that endpoint as expected
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.