Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.2.x
-
Fix Version/s: None
-
Component/s: Transport: JMS
-
Labels:None
-
Environment:
Windows 7
-
User impact:Medium
-
Configuration:
-
Similar Issues:None
Description
The config in this jira can be found in the test project at:
http://dev.ee.mulesource.com/repos/mulesource/sandbox/mule-tests-cluster-manual/
The issue is that when using a jms reply-to channel and a custom correlation aggregator to collect the split messages, the expected size of the messages to collect is being set to -1 by Mule. That field is being correctly set to the number of messages which were split when the vm transport is used instead (in the config in this jira, edit the 2 global endpoints "outboundSplitFlow" and "replyAggregatorFlow" to use vm).
Description of the config:
A collection splitter is used to split the incoming list of comma separated integers (e.g. 2,1,4,3). The individual messages are sent to a flow with a component to turn them to an Integer. They are then sent to the reply-to channel where they are aggregated and sorted by the custom aggregator. The custom aggregator is included as an attachment to this jira.
In both cases, the "expected size" is set the same way: from the MULE_CORRELATION_GROUP_SIZE property of the message. In the VM case, the property is simply carried along with the message as it moves into and out of the queue. Can you see where it's getting lost in the JMS case?