Search code examples
mulemule-studiomule-elmule-component

Collection aggregator not aggregating response properly Mule ESB


I have flow, where I will have multiple Item under the root Tag Items. I have splitter where it splits each items and doing some processing. After that I'm collecting all the response using Collection aggregator.

In my flow, Observed collection aggregator waiting for something though all the response are already reached aggregator. There is no response is being collected after aggregator ( since it is waiting for some response). But I'm sure ( if the Items has 5 item in it), all the response is being reach aggregator. But not sure why aggregator is still not passing its output(But sometime it is passing)

If I have kept timeout 30000 in aggrgegator and failed on Timeout ="false", now it is been passed out and it is aggregating the response ( 5 items).

But I'm pretty sure, message are reached aggregator within 20000 ms. But it is keep on waiting for something :(.

Why this behaviour from collection aggregator. Do any one have clue?. Please find the config..

    <flow name="Items" doc:name="Items">
    <vm:inbound-endpoint exchange-pattern="one-way" path="QUEUE" connector-ref="VM_Q1" doc:name="QUEUE">
    </vm:inbound-endpoint>
    <splitter expression="#[xpath('/Items/Item')]" doc:name="Splitter"/>
  <vm:outbound-endpoint exchange-pattern="one-way" path="OUT1" connector-ref="MAIN_VM" doc:name="Test Queue">
 </flow>

  <flow name="Items1" doc:name="Items">
  <vm:inbound-endpoint exchange-pattern="one-way" path="OUT1" connector-ref="MAIN_VM" doc:name="Test Queue"/>
.............doing some transformation and processing.....
<collection-aggregator failOnTimeout="true" doc:name="Collection Aggregator"/>  
  </flow>

Using version: 3.5.1 How we can track what exactly it is wait?. I have kept logger and checked all the 5 items are populating before aggregator. Help will be more appreciated.Thanks.

Edited: Logs after splitter component each iteration of Item

  After splitter:{MULE_CORRELATION_SEQUENCE=1, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686}
 After splitter:{MULE_CORRELATION_SEQUENCE=2, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686}
 After splitter:{MULE_CORRELATION_SEQUENCE=3, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686}
 After splitter:{MULE_CORRELATION_SEQUENCE=4, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686}
 After splitter:{MULE_CORRELATION_SEQUENCE=5, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686}

Log before collection aggregator

  Before Collection Aggregator:{MULE_CORRELATION_SEQUENCE=1, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=13783281-a036-11e4-a356-b8ee652d2686, Content-Type=text/plain;charset=UTF-8}
  Before Collection Aggregator:{MULE_CORRELATION_SEQUENCE=2, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686, Content-Type=text/plain;charset=UTF-8}
  Before Collection Aggregator:{MULE_CORRELATION_SEQUENCE=2, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686, Content-Type=text/plain;charset=UTF-8}
  Before Collection Aggregator:{MULE_CORRELATION_SEQUENCE=2, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686, Content-Type=text/plain;charset=UTF-8}
 Before Collection Aggregator:{MULE_CORRELATION_SEQUENCE=2, MULE_CORRELATION_GROUP_SIZE=5, MULE_ENCODING=UTF-8, MULE_CORRELATION_ID=9f7447b1-a03b-11e4-85dd-b8ee652d2686, Content-Type=text/plain;charset=UTF-8} 

@David please suggest. MULE_CORRELATION_SEQUENCE=2 is repeating multiple times. But the fetching payload is correct and different for each correlation_seq=2. How can be this issue resolved?


Solution

  • My gut feel is that something in doing some transformation and processing is damaging these control properties, which prevents the aggregation to work.

    I realize it's easy to point a finger at what's not shown above but the logs show a clear alteration of the control properties so it has to happen somewhere in this elicited block.