Bug 876274 - RollupClone - SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
RollupClone - SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when ...
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.3.0 GA
Unspecified Unspecified
high Severity high
: ER1
: 5.3.1
Assigned To: Matej Melko
Matej Melko
: 881910 881919 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-11-13 12:22 EST by Rick Wagner
Modified: 2018-03-23 17:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
SyncServiceInvoker sets the ReplyTo and FaultTo headers of the Call to null and they remain as null unless an Exception is thrown, in which case they will be set back to their original values. Now the ReplyTo and FaultTo headers also retain their original values when the process method succeeds, as expected.
Story Points: ---
Clone Of: 865728
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBESB-3772 Major Resolved SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful 2014-01-19 18:50:01 EST

  None (edit)
Description Rick Wagner 2012-11-13 12:22:37 EST
+++ This bug was initially created as a clone of Bug #865728 +++

Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3772

I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.

One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.

How reproducible:
Easily by making a reproducer ESB service

Steps to Reproduce:
1. Make a ESB service which invokes SyncServiceInvoker action and a custom action in order
2. In the second custom action, write a logic which confirms that ReplyTo/FaultTo headers are erased after the invocation to SyncServiceInvoker
3. Run the ESB service to confirm the reported behaviour
Actual results:
ReplyTo/FaultTo headers are erased

Expected results:
ReplyTo/FaultTo headers should be retained

--- Additional comment from jira-update@redhat.com on 2012-10-12 05:19:50 EDT ---

Tadayoshi Sato <tadayosi@gmail.com> updated the status of jira JBESB-3772 to Resolved
Comment 1 Rick Wagner 2012-11-13 12:23:38 EST
This BZ is a clone of 865728, which was included in the first SOA-P 5.3 Roll up.
Comment 2 Rick Wagner 2012-11-29 14:12:53 EST
*** Bug 881910 has been marked as a duplicate of this bug. ***
Comment 3 Jiri Sedlacek 2012-12-20 04:36:11 EST
*** Bug 881919 has been marked as a duplicate of this bug. ***
Comment 4 Jiri Sedlacek 2012-12-20 04:37:44 EST
verified in soa-p-5.3.1.ER1 by rbalent@redhat.com

Note You need to log in before you can comment on or make changes to this bug.