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

Http transport does not maintain correlation id on sync outbound requests

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix or Usage Issue
    • Affects Version/s: 2.2.1
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      JDK 1.6.0_20

    • User impact:
      Medium
    • Similar Issues:

      Description

      Mule appears not to maintain the MuleProperties.MULE_CORRELATION_ID_PROPERTY across synchronous outbound cxf/http calls.

      Example config (first section is always used, the second section shows a working example using vm queues only and the third section shows a non working example with a cxf client call to a remote server).

      <!-- main service -->	
      		<service name="asyncservice">
      			<inbound>
      				<vm:inbound-endpoint path="inbound.queue" synchronous="true"/>
      			</inbound>
      
      			<outbound>
      				<pass-through-router >
      					<vm:outbound-endpoint path="external.service"/>
      					<reply-to address="vm://external.service.response"/> 
      				</pass-through-router>
      			</outbound>
      			
      			<async-reply timeout="2000" failOnTimeout="true">
      				<vm:inbound-endpoint path="external.service.response"/>
      				<single-async-reply-router/>
      			</async-reply>
      		</service>	
      

      This one works (only using vm transport)

      <!-- mock service answering via VM  - this one maintains the correlation id -->
      		<service name="mockservice">
      			<inbound>
      				<vm:inbound-endpoint path="external.service" synchronous="true"/>
      			</inbound>
      			<outbound>
      				<pass-through-router>
      					<vm:outbound-endpoint path="external.service.test" synchronous="true"/>
      				</pass-through-router>
      			</outbound>
      		</service>
      		<service name="mockhttpservice">
      			<inbound>
      				<vm:inbound-endpoint path="external.service.test" synchronous="true"/>
      			</inbound>
      			<component class="com.yourpackage.SimpleMockService" />
      		</service>
      

      This one does not work - it looses the correlation id during the http call, and hence the correlator fails

      <!-- real service that makes an external cxf/http call  - this one drops the correlation id-->	
      
      		<service name="realservice">
      			<inbound>
      				<vm:inbound-endpoint path="external.service" synchronous="true" />
      			</inbound>
      			<outbound>
      				<pass-through-router>
      					<cxf:outbound-endpoint address="$url}" clientClass="cxf.clientClass" synchronous="true"
      						wsdlPort="wsdlPo9rt" wsdlLocation="classpath:schema/service.wsdl" operation="service" />
      				</pass-through-router>
      			</outbound>
      		</service>
      

      Adding this code to the org.mule.transport.http.HttpClientMessageDispatcher maintains the correlation id, and hence the service works.

      Method: protected MuleMessage doSend(MuleEvent event) throws Exception

      insert around line 275 after

       Header[] headers = httpMethod.getResponseHeaders();
       HttpMessageAdapter adapter = new HttpMessageAdapter(new Object[] { body, headers });
      
      // Set correlation properties if exists
      if ((adapter.getProperty(MuleProperties.MULE_CORRELATION_ID_PROPERTY) == null) && (event.getMessage().getProperty(MuleProperties.MULE_CORRELATION_ID_PROPERTY) != null)) {
             adapter.setProperty(MuleProperties.MULE_CORRELATION_ID_PROPERTY, event.getMessage().getProperty(MuleProperties.MULE_CORRELATION_ID_PROPERTY));
      }
      

        Attachments

          Activity

            People

            • Assignee:
              evangelinamrm Evangelina Martinez Ruiz Moreno
              Reporter:
              seime Arne Seime
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: