JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options (Alt+g)
  • Create Issue
  • Mule
  • MULE-5534

CLONE - Message modifications are discarded when using Collection Aggregator

  • Agile Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 3.1.0
  • Fix Version/s: 3.1.4 (EE only), 3.2.3 (EE only), 3.3.1
  • Component/s: Core: (other)
  • Labels:
    None
  • 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:
    None

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

relates to

Bug - A problem which impairs or prevents the functions of the product. MULE-5860 Inserting <collection-splitter /><collection-aggregator /> into a flow produces unexpected results

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Hide
Permalink
Dawid Wróbel added a comment - 25/Apr/11 11:31 PM

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 - 25/Apr/11 11:31 PM 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
Permalink
Pablo Kraan added a comment - 15/Jul/12 09:02 AM

Fixed on MULE-5860

Show
Pablo Kraan added a comment - 15/Jul/12 09:02 AM Fixed on MULE-5860

People

  • Assignee:
    Pablo Kraan
    Reporter:
    Dawid Wróbel
Vote (2)
Watch (1)

Dates

  • Created:
    25/Apr/11 11:27 PM
    Updated:
    15/Jul/12 09:02 AM
    Resolved:
    15/Jul/12 09:02 AM

Agile

  • View on Board
  • Atlassian JIRA (v5.0.7#734-sha1:8ad78a6)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.