JMSMessageToObject fails to set Correlation-ID when passed as inbound property

Details

Type: Patch submission
Status: Closed
Priority: Critical
Resolution: Fixed
Affects Version/s: 3.1.2
Fix Version/s: 3.1.4 (EE only), 3.2.2 (EE only)
Component/s: Transport: JMS
Labels:
- correlationid
- jms

User impact:
High
Similar Issues:
None
Effort:
XS

Description

The jms: object-to-jmsmessage-transformer fails to set the correlation ID if it is contained in the inbound scope instead of the outbound scope (which probably is when the correlation ID has been set in a previous service).

The class org.mule.transport.jms.transformers. AbstractJmsTransformer iterates through all outbound properties and sets the correlationID when it reaches MULE_CORRELATION_ID_PROPERTY. The correlation ID doesn´t necessarily have to be defined as outbound property (which can also be seen in org.mule. DefaultMuleMessage#getCorrelationId()). I´ll attach a suggestion for a fix of this bug.

As temporary workaround one can add the correlation ID to the outbound scope using the following message-property-transformer:
<message-properties-transformer scope="outbound">
<add-message-property key="MULE_CORRELATION_ID" value="#[mule:message.correlationId]" />
</message-properties-transformer>

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

AbstractJmsTransformer.java

19/Oct/11 07:57 AM

7 kB

Tarik Osman
AbstractJmsTransformer.patch

19/Oct/11 07:57 AM

2 kB

Tarik Osman
Hide
testcase-5838.zip

04/Nov/11 08:37 AM

2 kB

Tarik Osman
META-INF/MANIFEST.MF 0.1 kB

test/resources/integration/jms-5838.xml 3 kB

test/resources/.../connector-jms-5838.xml 1 kB

test/java/.../Jms5838TestCase.java 1 kB

Download Zip
Show

testcase-5838.zip

04/Nov/11 08:37 AM

2 kB

Tarik Osman

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Tarik Osman added a comment - 19/Oct/11 07:57 AM

Suggested fix

Show

Tarik Osman added a comment - 19/Oct/11 07:57 AM Suggested fix

Tarik Osman made changes - 19/Oct/11 07:57 AM

Field	Original Value	New Value
Attachment		AbstractJmsTransformer.java [ 14405 ]
Attachment		AbstractJmsTransformer.patch [ 14406 ]

Daniel Feist made changes - 03/Nov/11 11:10 AM

Issue Type

Bug [ 1 ]

Patch submission [ 5 ]

Hide

Permalink

Mike Schilling added a comment - 03/Nov/11 11:12 AM

Please attach a test case to the bug.

Show

Mike Schilling added a comment - 03/Nov/11 11:12 AM Please attach a test case to the bug.

Hide

Permalink

Tarik Osman added a comment - 04/Nov/11 08:37 AM

The testcase is intended to run in the JMS transport maven module.

Show

Tarik Osman added a comment - 04/Nov/11 08:37 AM The testcase is intended to run in the JMS transport maven module.

Tarik Osman made changes - 04/Nov/11 08:37 AM

Attachment

testcase-5838.zip [ 14510 ]

Hide

Permalink

Tarik Osman added a comment - 04/Nov/11 08:46 AM

This bug only seems to occur in combination with the multicasting-router and cannot be reproduced with a pass-through-router (nor does it occur if a VM-Connector is used instead of JMS). I assume that it may also be a side effect of the enableCorrelation Attribute of the multicasting-router.

Show

Tarik Osman added a comment - 04/Nov/11 08:46 AM This bug only seems to occur in combination with the multicasting-router and cannot be reproduced with a pass-through-router (nor does it occur if a VM-Connector is used instead of JMS). I assume that it may also be a side effect of the enableCorrelation Attribute of the multicasting-router.

Mike Schilling made changes - 10/Nov/11 11:03 AM

Priority

To be reviewed [ 6 ]

Critical [ 2 ]

Daniel Feist made changes - 18/Nov/11 10:43 AM

Fix Version/s

New Backlog [ 11111 ]

Daniel Feist made changes - 30/Nov/11 02:21 PM

Effort

Stephen Fenech made changes - 22/Jan/12 12:47 AM

Assignee

Stephen Fenech [ stephenfenech ]

Hide

Permalink

Stephen Fenech added a comment - 22/Jan/12 03:29 AM

I would say that the bug is not in the AbstractJmsTransformer but rather in the AbstractSequenceRouter (parent of multicast router), that is why the flow works with passthrough and not with the multicaster. The passthrough calls the getRoute on the FilteringOutboundRouter which calls the propagateMagicProperties which copies the MULE_CORRELATION_ID_PROPERTY from inbound to outbound. This is not done by the AbstractSequenceRouter and so these values are not copied over.

In the case of the VM transport, it works due to the way messages are changed from outbound to inbound and thus copies the inbound MULE_CORRELATION_ID_PROPERTY to the outbound scope.

A working fix would be to use the getRoute(i,Event) method instead of routes.get

Show

Stephen Fenech added a comment - 22/Jan/12 03:29 AM I would say that the bug is not in the AbstractJmsTransformer but rather in the AbstractSequenceRouter (parent of multicast router), that is why the flow works with passthrough and not with the multicaster. The passthrough calls the getRoute on the FilteringOutboundRouter which calls the propagateMagicProperties which copies the MULE_CORRELATION_ID_PROPERTY from inbound to outbound. This is not done by the AbstractSequenceRouter and so these values are not copied over. In the case of the VM transport, it works due to the way messages are changed from outbound to inbound and thus copies the inbound MULE_CORRELATION_ID_PROPERTY to the outbound scope. A working fix would be to use the getRoute(i,Event) method instead of routes.get

stephen.fenech

30/Jan/12 10:57 PM

View full commit

MULE-5838 : AbstractSequenceRouter uses the getRoute method instead of getting the route directly from the routes list in order for the propagation of "magic" properties. git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.1.x@23761 bf997673-6b11-0410-b953-e057580c5b09

3.1.x

-1

core/src/main/java/org/mule/routing/outbound/AbstractSequenceRouter.java

+63

-4

core/src/test/java/org/mule/routing/outbound/MulticastingRouterTestCase.java

stephen.fenech

30/Jan/12 11:40 PM

View full commit

Merged revisions 23761 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.1.x ........ r23761 | stephen.fenech | 2012-01-31 06:57:13 +0200 (Tue, 31 Jan 2012) | 1 line MULE-5838 : AbstractSequenceRouter uses the getRoute method instead of getting the route directly from the routes list in order for the propagation of "magic" properties. ........ git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.2.x@23763 bf997673-6b11-0410-b953-e057580c5b09

mule-3.2.x

-1

core/src/main/java/org/mule/routing/outbound/AbstractSequenceRouter.java

+63

-4

core/src/test/java/org/mule/routing/outbound/MulticastingRouterTestCase.java

stephen.fenech

30/Jan/12 11:45 PM

View full commit

Merged revisions 23763 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.2.x ................ r23763 | stephen.fenech | 2012-01-31 07:40:30 +0200 (Tue, 31 Jan 2012) | 9 lines Merged revisions 23761 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.1.x ........ r23761 | stephen.fenech | 2012-01-31 06:57:13 +0200 (Tue, 31 Jan 2012) | 1 line MULE-5838 : AbstractSequenceRouter uses the getRoute method instead of getting the route directly from the routes list in order for the propagation of "magic" properties. ........ ................ git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@23764 bf997673-6b11-0410-b953-e057580c5b09

mule-3.3.3

-1

core/src/main/java/org/mule/routing/outbound/AbstractSequenceRouter.java

+63

-4

core/src/test/java/org/mule/routing/outbound/MulticastingRouterTestCase.java

Hide

Permalink

Stephen Fenech added a comment - 30/Jan/12 11:54 PM

Fixed in :
3.1.x Commit : 23761 :https://fisheye.codehaus.org/changelog/mule/?cs=23761
3.2.x Commit : 23763 :https://fisheye.codehaus.org/changelog/mule/?cs=23763
3.x Commit : 23764 :https://fisheye.codehaus.org/changelog/mule/?cs=23764

Show

Stephen Fenech added a comment - 30/Jan/12 11:54 PM Fixed in : 3.1.x Commit : 23761 :https://fisheye.codehaus.org/changelog/mule/?cs=23761 3.2.x Commit : 23763 :https://fisheye.codehaus.org/changelog/mule/?cs=23763 3.x Commit : 23764 :https://fisheye.codehaus.org/changelog/mule/?cs=23764

Hide

Permalink

Daniel Feist added a comment - 02/Feb/12 07:16 AM

Stephen, can this be closed?

Show

Daniel Feist added a comment - 02/Feb/12 07:16 AM Stephen, can this be closed?

Stephen Fenech made changes - 07/Feb/12 12:59 PM

Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Pablo Kraan made changes - 15/Feb/12 08:45 AM

Status	Closed [ 6 ]	Reopened [ 4 ]
Resolution	Fixed [ 1 ]

Pablo Kraan made changes - 15/Feb/12 08:45 AM

Resolution		Fixed [ 1 ]
Fix Version/s	New Backlog [ 11111 ]
Fix Version/s		3.2.2 (EE only) [ 11105 ]
Fix Version/s		3.1.4 (EE only) [ 11079 ]
Status	Reopened [ 4 ]	Closed [ 6 ]

Transition

Time In Source Status

Execution Times

Last Executer

Last Execution Date

Open

Closed

111d 6h 4m

Stephen Fenech

07/Feb/12 12:59 PM

Closed

Reopened

7d 19h 45m

Pablo Kraan

15/Feb/12 08:45 AM

Reopened

Closed

24s

Pablo Kraan

15/Feb/12 08:45 AM

This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

Repository mule on http://foo.bar/ failed: Error in remote call to 'FishEye 0 (http://foo.bar/)' (http://foo.bar) [AbstractRestCommand{path='/rest-service-fe/changeset-v1/listChangesets/', params={expand=changesets[-21:-1].revisions[0:29], comment=MULE-5838, p4JobFixed=MULE-5838, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar

People

Assignee:

Stephen Fenech

Reporter:

Tarik Osman

Vote (1)

Watch (3)

Dates

Created:

19/Oct/11 07:55 AM

Updated:

15/Feb/12 08:45 AM

Resolved:

15/Feb/12 08:45 AM

Time Tracking

Estimated:

Remaining:

Logged:

Not Specified

Agile

View on Board