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:
-
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>
Activity
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
Suggested fix