WMQ Backout Queue Concept in Mule ESB - not able to work efficently

Question

I'm really struck in this concept. I have a WMQ input queue named "IN" ( configured backout queue for this queue named "BACKOUT" in WMQ with thresold value as 4). As expected it is doing 3 times retry and finally BACKOUT queue count is being increased but when i try to browse the message i'm not able to see those messages. Once i stop the mule flow and restart the WMQ explorer, i'm able to see the messages in "BACKOUT". Please find my configuration xml. Please help me on this. Thanks in advance.

Googled it and found it is problem with Transaction not being commited. But not able to resolve the problem even after many trials. Kindly help.

    <?xml version="1.0" encoding="UTF-8"?>
    <wmq:connector name="WMQ_Connector" hostName="hostName" port="1portName" queueManager="QM" channel="Channel" validateConnections="true" doc:name="WMQ Connector" disableTemporaryReplyToDestinations="true"/>
   <flow name="BackoutFlow1" doc:name="BackoutFlow1">
    <wmq:inbound-endpoint  queue="IN" connector-ref="WMQ_Connector" doc:name="WMQ" exchange-pattern="request-response" >

        <wmq:transaction action="ALWAYS_BEGIN"/>

    </wmq:inbound-endpoint>
        <logger message="*******#[payload]****" level="INFO" doc:name="Logger"/>
        <set-payload value="#[hi]" doc:name="Set Payload"/>

    <wmq:outbound-endpoint queue="OUT" connector-ref="WMQ_Connector" doc:name="WMQ">
        <wmq:transaction action="NONE"/>
    </wmq:outbound-endpoint>
</flow>

T.Rob T.Rob · Accepted Answer · 2014-04-07T16:52:01

WebSphere MQ writes that message to the backout queue under syncpoint. But it does not know the context of the application and without that it does not know whether to COMMIT on your behalf or not. As a general rule, WMQ tries to not do irreversible things implicitly but rather requires explicit action on the part of the program.

In theory, the program knows when issuing a BACKOUT and can immediately issue a COMMIT if it wants, or else continue processing messages and include the backed out message in the next unit of work. The program can, for example, look at the backout count of the message to determine if a given message is new or is being redelivered.

You are not able to see the message while it is under syncpoint when in the backout queue. Apparently when you stop Mule, a COMMIT is being issued. If the application that caused the backout is killed rather than being stopped in an orderly fashion, the usual result is that the message is requeued to the input queue due to the implicit ROLLBACK command.

To see the message without having to stop Mule, either issue a COMMIT in the program or else put a second message in the queue that will be read and committed and not be rolled back. The COMMIT on that second message will also COMMIT the backed out message in the backout queue.

WMQ Backout Queue Concept in Mule ESB - not able to work efficently

1 Answers