[
http://jira.jboss.com/jira/browse/JBESB-1774?page=comments#action_12414749 ]
Mika Leino commented on JBESB-1774:
-----------------------------------
I uploaded a log file and new service configurations to illustrate the problem. And yes,
the message going to service B is the same message that service A has received as our
understanding of the documentation has been that the message is returned to the client
invoking that service, in this case service A.
In our setup service A should do some additional work on the message before returning it
to the client and process all errors received from service B. The documentation states
that in "RequestResponse" action pipelines the message is returned to the client
after the last action and also that when invoking other services a service is acting as a
client to the service invoked. Thus it would seem logical that when service A invokes
service B with ServiceInvoker.deliverSync the message would be returned to service A
instead of the actual client.
Even if the behaviour of returning the message from service B to the client would be by
design this raises another issue in that the message is not routed identically when
retrying delivery. This might cause some unwanted results and is very misleading.
Messages are returned to client from the wrong service
------------------------------------------------------
Key: JBESB-1774
URL:
http://jira.jboss.com/jira/browse/JBESB-1774
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.2.1 CP1
Environment: Windows Server 2003
Reporter: Mika Leino
Attachments: service_A_jboss-esb.xml, service_A_jboss-esb.xml,
service_B_jboss-esb.xml, service_B_jboss-esb.xml, services_log.txt
We have a setup in which a client calls an ESB service (service A) with a webservice
interface and this service then calls on another ESB service (service B). Both of the
services have their action pipelines set to be "RequestResponse".
For some reason the first attempt to handle the client's message always fails as the
message is returned to the client from service B. As the message never returns to service
A it assumes an unresponsive EPR and resends the message which on the second attempt
returns to service A.
The first attempt looks like this:
client -> service A -> service B -> client
And the second like this:
(client ->) service A -> service B -> service A -> client
Unfortunately the client interpreters the first response as the one it is waiting for and
fails as service A has not made the necessary changes to the message. The second attempt
produces a valid response but the client is no longer listening for it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira