CODEWITHSUNDEEP
mule
jon lee
jon lee

Reputation: 887

Mule - mixing exchange patterns

I am trying to understand what is going one when i mix exchange patterns.

If i call a vm request-response inbound endpoint with a ones-way outbound endpoint, there is no error but it appears as though the flow is never run for example:

    <flow name="main" doc:name="main" processingStrategy="asynchronous">
        <poll frequency="60000">
            <set-payload value="main"></set-payload>
        </poll>
        <set-variable value="xxx" variableName="var1"></set-variable>
        <logger level="ERROR" message="MAIN1 #[flowVars.var1]" />

        <vm:outbound-endpoint address="vm://vm" />
        <logger level="ERROR" message="MAIN2 #[flowVars.var1]" />
    </flow>


    <flow name="p1">
        <vm:inbound-endpoint address="vm://vm" exchange-pattern="request-response" />
        <logger level="ERROR" message="PRIVATE #[flowVars.var1]" />
    </flow>
</mule>

This configuration logs the following, but never prints 'PRIVATE xxx'.

ERROR 2014-03-26 13:22:35,794 [[test].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: MAIN1 xxx ERROR 2014-03-26 13:22:35,812 [[test].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: MAIN2 xxx INFO 2014-03-26 13:22:35,816 [[test].connector.VM.mule.default.dispatcher.01] org.mule.lifecycle.AbstractLifecycleManager: Initialising: 'connector.VM.mule.default.dispatcher.784920740'. Object is: VMMessageDispatcher INFO 2014-03-26 13:22:35,817 [[test].connector.VM.mule.default.dispatcher.01] org.mule.lifecycle.AbstractLifecycleManager: Starting: 'connector.VM.mule.default.dispatcher.784920740'. Object is: VMMessageDispatcher

And if I mix them the other way around MAIN2 xxx never prints. Can someone explain what actually is going on here?

Upvotes: 1

Views: 860

Answers (2)

Guido
Guido

Reputation: 351

I don't mean to be rude, but It doesn't make sense to mix echange patterns this way. I believe one should never do something like this. In fact it's better to configure your exchange pattern on the vm endpoint globally, so that you have have consistent endpoints and you can't make mistakes.

<vm:endpoint name="vm-endp" path="vm-endp" exchange-pattern="request-response" />

<flow name="main" doc:name="main" processingStrategy="asynchronous">
    <http:inbound-endpoint exchange-pattern="one-way" name="http-endpoint" host="localhost" port="2003" path="mule" doc:name="HTTP"/>
    <set-variable variableName="var1"  value="xxx"  doc:name="XXX" />
    <logger level="INFO" message="MAIN1 #[flowVars.var1]" />
    <set-payload value="#[flowVars.var1]" />
    <vm:outbound-endpoint ref="vm-endp" />
    <logger level="INFO" message="MAIN2 #[flowVars.var1]" />
    <logger level="INFO" message="PAYLOAD #[message.payloadAs(java.lang.String)]" />
</flow>

<!-- flowVars are FLOW VARIABLES, hence they're not accessible from multiple flows -->

<flow name="flow">
    <vm:inbound-endpoint ref="vm-endp" />
    <logger level="INFO" message="PRIVATE #[flowVars.var1]" />
    <append-string-transformer message=" added to the payload" />
</flow>

It should output:

INFO [[VMtest].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: MAIN1 xxx
INFO [[VMtest].main.stage1.01] org.mule.lifecycle.AbstractLifecycleManager: Initialising: 'connector.VM.mule.default.dispatcher.1221995064'. Object is: VMMessageDispatcher
INFO [[VMtest].main.stage1.01] org.mule.lifecycle.AbstractLifecycleManager: Starting: 'connector.VM.mule.default.dispatcher.1221995064'. Object is: VMMessageDispatcher
INFO [[VMtest].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: PRIVATE null
INFO [[VMtest].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: MAIN2 xxx
INFO [[VMtest].main.stage1.01] org.mule.api.processor.LoggerMessageProcessor: PAYLOAD xxx added to the payload

Upvotes: 0

Anton Kupias
Anton Kupias

Reputation: 4015

Mule docs state the following:

request-response:

When using request-response endpoints, messages are delivered directly from an outbound vm endpoint to the inbound vm endpoint that is listening on the same path. This delivery is blocking and occurs in the same thread. If there is no inbound request-response vm endpoint in the same Mule application listening on this path, then dispatching of the message from the outbound endpoint will fail.

one-way:

When using one-way endpoints, messages are delivered to the corresponding inbound endpoint via a queue. This delivery is non-blocking. If there is no inbound one-way endpoint in the same Mule application listening on this path, then, although dispatching of the message will succeed, the message will remain in the queue. By default, this queue is in memory, but it is also possible to configure a persistent queue that will use the file system as its persistence mechanism.

http://www.mulesoft.org/documentation/display/current/VM+Transport+Reference

I would guess the case with request-response outbound just remains waiting for a response, as the message gets dispatched and received contrary to the docs.

Upvotes: 1

Related Questions