Uploaded image for project: 'Mule'
  1. Mule
  2. MULE-5534

CLONE - Message modifications are discarded when using Collection Aggregator


    • User impact:
    • Configuration:
      <service name="MainService">
          <inbound-endpoint address="vm://mainService"
                            responseTransformer-refs="MessageListToResponseBean ResponseBeanToDom"/>
                <outbound-endpoint address="vm://otherService" remoteSync="true"/>
      <service name="OtherService">
              <vm:inbound-endpoint path="otherService" remoteSync="true"/>
                  <outbound-endpoint address="vm://fooService" remoteSync="true" />
                  <outbound-endpoint address="vm://barService" remoteSync="true" />
      <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:


      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.

      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



              • Assignee:
                pablo.kraan Pablo Kraan
                dawidw Dawid Wróbel
              • Votes:
                2 Vote for this issue
                1 Start watching this issue


                • Created:
                  Fix Release Date:

                  Zendesk Support