1. Mule
  2. MULE-3302

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


    • User impact:
    • Effort points:
    • Similar Issues:
      MULE-3300VMRequestorTestCase fails due to message scribbling
      MULE-4596Access Denied Responses for valid requests under load
      MULE-6808When running salesforce operations in parallel (with Oauth integration), in some scenarios we are getting an exception related to the access token for Oauth
      MULE-8712Async HTTP client sometimes returns a null response
      MULE-1197ORIGINALNAME not parsed under certain circumstances
      MULE-2172Patch to PollingHttpMessageReceiver for conditional GET
      MULE-3314Response messages in remoteSync=false scenarios are corrupted by transformations that happen in outbound phase
      MULE-7654Mule stops receiving messages under heavy load
      MULE-8428Expression support for certain message processors
      MULE-2301"Socket Address in Use" error under high load


      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.

        Issue Links


          No work has yet been logged on this issue.


            • Assignee:
              Ross Mason
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: