We still get Message scribbling under certain conditions (Request Response) (It gets caught but we need to remove the underlying probblem)

• User impact:

  Medium
• Effort points:

  10
• Similar Issues:

  None

From Dan D.
I was getting slightly annoyed by the build server today so I tracked down a reliable way to reproduce this issue. To reproduce this issue locally just add a Thread.sleep(1000) to VMMessageRequester at line 89 - right after the resetAccessControl().

I think I can even explain the issue here. We have thread #1 which sends off a message which is in essence "new DefaultMuleMessage(new DefaultMuleMessageAdapter());"

Thread #2 (i.e. the main thread in the test case), picks this up via the VMMessageRequester and calls resetAccessControl().

So far so good, except this message has been sent with MuleClient.send() so its going to build a response using the request message's properties. This happens in MuleClient:330:

response = OptimizedRequestContext.unsafeRewriteEvent(response);

This eventually calls RequestContext.newMessage(message) which creates a copy of the message by doing new DefaultMuleMessage(payload, originalMessageAdapter) and resets the MessageAdapter that is also being picked up by the VMMessageRequester. Since it is not deterministic whether this happens after or before the VMMessageRequester gets the message and resets the access control, sometimes it fails and sometimes it doesn't.