1
votes

Using version 4.0.3, I currently have an IN and OUT sequence participating in a JMS-to-HTTP proxy defined with a fault handler that will successfully roll back the JMS local transaction if there is an exception, however a fault is not thrown in the case that a SOAPFault is returned in the response (only a WARN message from ClientHandler), therefor I lose the original JMS message (it is committed). I should note that if I parse the response in the OUT sequence and discover the fault there, performing the rollback there has no effect since, by the time it gets to the OUT sequence, the JMS transaction is committed.

I have found the following "resolved fixed" Jira ticket for the next release of WSO2 ESB which may seem to solve my issue but do not have the luxury of waiting for this release to get this working: https://wso2.org/jira/browse/ESBJAVA-906

My question is, are there any workarounds available that I can implement in 4.0.3? Is there a way to possibly block the thread performing the commit until I can determine the result, etc? If not, can you reference the source code for the new release so I can supply the necessary fault myself into the synapse ClientHandler (or similar) per the fix implemented in the Jira ticket?

Here is the warning I receive (that I need to be an ERROR) along with some extra debug info:

TID: [] [WSO2 ESB] [2012-04-18 17:18:23,786]  INFO {org.apache.synapse.core.axis2.TimeoutHandler} -  This engine will expire all callbacks after : 86400 seconds, irrespective of the timeout action, after the specified or optional timeout {org.apache.synapse.core.axis2.TimeoutHandler}
TID: [] [WSO2 ESB] [2012-04-18 17:18:23,790] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  Callback added. Total callbacks waiting for : 1 {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,006]  WARN {org.apache.synapse.transport.nhttp.ClientHandler} -  Received an internal server error : Internal Server Error For : 127.0.0.1:8080 For Request : Axis2Request [Message ID : urn:uuid:6322ced4-801f-40fe-a3a7-bb4019b02cdb] [Status Completed : true] [Status SendingCompleted : true] {org.apache.synapse.transport.nhttp.ClientHandler}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,015] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  Callback removed for request message id : urn:uuid:6322ced4-801f-40fe-a3a7-bb4019b02cdb. Pending callbacks count : 0 {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,016] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  Synapse received an asynchronous response message {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,016] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  Received To: null {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,017] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  SOAPAction:  {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,017] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  WSA-Action:  {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,021] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} -  Body :
<?xml version='1.0' encoding='utf-8'?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Server</faultcode>       
      <faultstring>org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.</faultstring>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

{org.apache.synapse.core.axis2.SynapseCallbackReceiver}

1

1 Answers

0
votes

I was able to solve, though not in the way I had hoped; was trying to avoid modifying Synapse behavior:

Altering the org.apache.synapse.transport.nhttp.ClientHandler allowed me to throw a fault for this type of condition (SOAP fault) which executes fault sequence performing the rollback before marking the request as completed. (I'm also hoping I can trap transport exceptions such as connection failure to execute rollback in a similar fashion since this is another surprising hole in the capability of Synapse to allow transacted message delivery). I'm starting to wonder if anyone really uses this for this type of JMS-to-HTTP pattern in the enterprise since, as it is implemented, there is great opportunity for message leakage, for example of there if the endpoint is down or throws a SOAP fault. I have looked at the alternate "store and forward" patterns but this is asynchronous and requires that the message store queue be recoverable and available across distributed ESBs in the case of outage or failure - which I already have with my primary message queuing system. For this reason, I feel like transactional JMS is the way to go. Am I missing something? Is there a better pattern I should be considering with Synapse/WSO2 (with the understanding that I need to do synchronous JMS-to-HTTP/SOAP brokering with near-zero message loss)?