About Mule 3.3 CE:
Even though I have an asynchronous "one-way" exchange pattern it replies twice to the caller with "empty" messages before my real response. So I get three responses. The first two are just empty "crap" and then I get my real response back.
Can I disable the first two "empty" responses and just get my real response back to where I should reply it. The caller sets up an TEMP-queue for the response from my flow. (As now it gets three respones on that response-queue.)
Do we need to change behaviour in ActiveMQ? It is default as of now.
<jms:activemq-connector name="Active_MQ_Staging" brokerURL="tcp://xxx.xxx.xxx.x:yyyy" validateConnections="true" maxRedelivery="2" doc:name="Active MQ" forceJndiDestinations="true" honorQosHeaders="true" specification="1.1" disableTemporaryReplyToDestinations="true"/>
<flow name="MyFlow2" doc:name="MyFlow2">
<jms:inbound-endpoint queue="myQueue" connector-ref="Active_MQ_Staging" doc:name="JMS" exchange-pattern="one-way"/>
<all doc:name="All">
<processor-chain>
<jms:outbound-endpoint queue="${queue.mule.levinforequest}" disableTemporaryReplyToDestinations="true" connector-ref="Active_MQ_Staging" doc:name="JMS"/>
</processor-chain>
<processor-chain>
<logger message="Leaving AppFacade" level="INFO" doc:name="Logger"/>
</processor-chain>
</all>
....
EDIT: Ok, I have not post all in the statement above.
This is what we want to do: The Mule-app will receive a JMS Message. The sender (which is a stateless EJB MDB if I'm correct) will setup a few properties that I need to carry with me and I will add a few more properties. The sender gives me the name of the temporary queue setup for a response (where the mule-app (in another flow) will respond after a few other steps and other integration). This first mule-flow have I setup as "one-way" because I do not want it to respond.
This first flow puts the message on another JMS Queue. Then another Mule-app(and muleflow) receives the message (one-way as well) and transform it to another format and put it on another queue. Maybe this doesn't make sense to you but in our environment it does. ;-) Then after receiving a response from a "third party" The second Mule-app receives a response and transform the JMS Message into our own format(we still have the properties with us). Now send it to a topic where the first Mule-app (and a 2nd flow) (or anyone else) can get the message. No we want to respond to the caller. We have properties on who sent the request and to what queue he wants the response to. So all 4 mule-flows(in 2 different mule-apps) are all setup as "one-way" because we want it asynchronous and not a response directly because there are several steps (and queues) on the way.
So we have the actual flow is going from Flow 1 to Flow 3 to external party and then getting a response in Flow 4 and then back to Flow 2 to the caller.
So Flow1->Flow3->Flow4->Flow2
Mule-app1:
Flow1: Caller -> Queue -> MuleFlow(one-way) -> Queue
Flow2: Topic -> MuleFlow (one-way) -> Reponse to the Temp-queue
Mule-App2
Flow3: Queue -> Muleflow(one-way) -> Transform -> Queue -> External Part
Flow4: External Part -> Queue-> MuleFlow(one-way) -> Transform -> Topic
I hope you can follow me on this.
I guess the Mule Studio has put those "Processor Chains" there. And the logging is just "logging". I want to know when leaving Flow1 and so on. Just for log/debug.
Thank you for you considerations in this matter.
/Z