wso2 ESB - Proxy - WebSphere MQ Input, WebSphere MQ Output - Without Message Loss - jms

Question

I am after the wso2 configuration/source code for a wso2 ESB proxy that can read from a WebSphere MQ Queue and write to a WebSphere MQ Queue. One way, no response.
We need reliability, i.e. the message can never be lost. No matter what the failure scenario. For any failures writing to the output queue, the message should be rolled-back to the input queue (this probably means the message should be read from the input queue using a transaction and/or client acknowledgement mode).
Examples of failures are:
Output queue full, MQRC 2053
Output queue does not exist, MQRC 2085
Output queue put inhibited
Output queue max msg size smaller than the size of the message to be sent.
Application does not have authority to send to output queue, MQRC 2035
Ideally we are trying to do this using just a wso2 ESB proxy, not a wso2 message store or wso2 message processor. Please clarify if this is possible to do using only the wso2 esb proxy, and not the other components. If this is not possible, please provide full configuration using the message store and message processor.
I am able to create a wso2 proxy to read from WebSphere MQ and write to WebSphere MQ, however in any of the failure scenarios above we lose messages.
Update at 1 June 2015: wso2 support have replicated this issue and are looking into supplying a fix/solution. I am using wso2 ESB 4.8.1.

Answer 1

In your proxy definition, add thoses parameters :
<parameter name="transport.jms.SessionAcknowledgement">CLIENT_ACKNOWLEDGE</parameter>
<parameter name="transport.jms.SessionTransacted">true</parameter>
In it's faultSequence : add this property :
<property name="SET_ROLLBACK_ONLY" value="true" scope="axis2"/>
You must not use "send" mediator in your inSequence, because it works asynchronously and the inSequence ends before the outSequence receive the response (or before the faultSequence receive the fault) : as soon as the inSequence ends, if property "SET_ROLLBACK_ONLY" has not been set, dequeue of the message is committed !
You can use "call" mediator. Property "ClientApiNonBlocking" can be usefull in some cases. You can use "filter" mediator after "call" mediator in your inSequence to analyse the response and decide to rollback the transaction setting "SET_ROLLBACK_ONLY" property.