Mule
  1. Mule
  2. MULE-5534

CLONE - Message modifications are discarded when using Collection Aggregator

    Details

    • User impact:
      High
    • Configuration:
      Hide
      <service name="MainService">
        <inbound>
          <inbound-endpoint address="vm://mainService"
                            responseTransformer-refs="MessageListToResponseBean ResponseBeanToDom"/>
        </inbound>
        <outbound>
          <pass-through-router>
                <outbound-endpoint address="vm://otherService" remoteSync="true"/>
          </pass-through-router>
        </outbound>
      </service>
      
      <service name="OtherService">
          <inbound>
              <vm:inbound-endpoint path="otherService" remoteSync="true"/>
          </inbound>
          <outbound>
              <multicasting-router>
                  <outbound-endpoint address="vm://fooService" remoteSync="true" />
                  <outbound-endpoint address="vm://barService" remoteSync="true" />
              </multicasting-router>
          </outbound>
      </service>
      
      Show
      <service name= "MainService" > <inbound> <inbound-endpoint address= "vm://mainService" responseTransformer-refs= "MessageListToResponseBean ResponseBeanToDom" /> </inbound> <outbound> <pass-through-router> <outbound-endpoint address= "vm://otherService" remoteSync= "true" /> </pass-through-router> </outbound> </service> <service name= "OtherService" > <inbound> <vm:inbound-endpoint path= "otherService" remoteSync= "true" /> </inbound> <outbound> <multicasting-router> <outbound-endpoint address= "vm://fooService" remoteSync= "true" /> <outbound-endpoint address= "vm://barService" remoteSync= "true" /> </multicasting-router> </outbound> </service>
    • Similar Issues:
      MULE-8590Define behavior to aggregate collections splitted with group size set as unknown
      MULE-5860Inserting <collection-splitter /><collection-aggregator /> into a flow produces unexpected results
      MULE-4112Collection aggregator router seems to require the inbound-endpoint to be synchronous
      MULE-6104request-reply router, collection-splitter and collection-aggregator triplet bug
      MULE-4457getting CopyOnWriteArrayList class cast error when using collection-aggregator-router
      MULE-6889Concurrent Modification Exception when using the Async Message Proccessor inside a foreach
      MULE-5749Expected size of the number of messages to aggregate being set to -1 when using a jms reply-to channel
      MULE-7728Collection aggregator fails with high amount of messages. Default in memory object store is inefficient.
      MULE-3623Collection aggregation router IMMEDIATE timeout exception
      MULE-5020Support other messaging patterns for aggregation

      Description

      I have a response transformer (it extends AbstractMessageAwareTransformer) that receives a DefaultMessageCollection object and does some logic before setting the payload to be a pojo. Another transformer then transforms the pojo into a DOM object, which is what the service should return. I can step through the code and this all happens as expected without errors or warnings.

      The problem is that instead of then returning the DOM object as the payload (as expected), the service returns the DefaultMessageCollection with the CopyOnWriteArrayList as it's payload. This seems incorrect to me. If I have a response transformer set the payload to a given object, I'd expect that to be what is returned.

      I've included a sample config to illustrate what's happening. There are no exceptions thrown. MainService is returning the MuleMessageCollection with an array payload instead of a regular MuleMessage with a DOM payload.

      Update:
      After studying the code I've found that the payload seems to be getting swapped out in the method called on line 333 of DefaultMuleSession:

      // See MULE-2692
      //RM* This actually performs the function of adding properties from the request to the response
      // message I think this could be done without the performance hit.
      //Or we could provide a way to set the request message as the OriginalAdapter on the message
      //And provide access to the request properties that way
      response = OptimizedRequestContext.unsafeRewriteEvent(response);

      Looking in the debugger, before this line is invoked, the response object is a DefaultMessageCollection and it's adapter and originalAdapter are both the DefaultMessageAdapter that contain the expected DOM message. After the call the adapter is switched to one that contains the CopyOnWriteArrayList as it's message.

      The above call to unsafeRewriteEvent ultimately invokes:
      RequestContext.internalRewriteEvent(message, RequestContext.UNSAFE);

      Which then returns a copy of the message generated via this call:
      RequestContext.newMessage(message, safe);

      Which makes a copy of the message like so:
      (MuleMessage) ((ThreadSafeAccess)message).newThreadCopy();

      Which returns a new DefaultMessageCollection with an unexpected payload:
      new DefaultMessageCollection(this);

      This is a significant blocker bug for us, so please let me know if there's any additional info I can provide to help.

        Issue Links

          Activity

          Hide
          Dawid Wróbel added a comment -

          I created this as a clone of http://www.mulesoft.org/jira/browse/MULE-4213 to emphasize that this issue also affects the 3.1.x series. I thought that I'd be able to edit its details prior to filing the bug report but I am not, so for for more information on how this affects the up-to-date mule version, please look at my comments in aforementioned MULE-4213.

          Show
          Dawid Wróbel added a comment - I created this as a clone of http://www.mulesoft.org/jira/browse/MULE-4213 to emphasize that this issue also affects the 3.1.x series. I thought that I'd be able to edit its details prior to filing the bug report but I am not, so for for more information on how this affects the up-to-date mule version, please look at my comments in aforementioned MULE-4213 .
          Hide
          Pablo Kraan added a comment -

          Fixed on MULE-5860

          Show
          Pablo Kraan added a comment - Fixed on MULE-5860

            People

            • Assignee:
              Pablo Kraan
              Reporter:
              Dawid Wróbel
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development