WSO2 ESB：如何响应SOAP错误执行JMS回滚？

Question

使用Version4.0.3，我现在有一个IN和OUT序列参与一个JMS到HTTP代理，该代理由一个错误处理程序定义，如果出现异常，该处理程序将成功回滚JMS本地事务，但是在响应中返回SOAPFault（只有来自ClientHandler的警告消息）的情况下不会引发错误，因此我丢失了原始JMS消息（它已提交）。我应该注意，如果我在OUT序列中解析响应并在那里发现错误，那么在那里执行回滚没有任何效果，因为当它到达OUT序列时，JMS事务已经提交。

我已经为下一个版本的WSO2 ESB找到了以下“已解决的固定”Jira票证，它似乎解决了我的问题，但没有时间等待这个版本来解决这个问题:https://WSO2.org/Jira/browse/esbjava-906

我的问题是，在4.0.3中有没有可以实现的变通方法？是否有一种方法可以阻止执行提交的线程，直到我可以确定结果等？如果没有，您是否可以引用新版本的源代码，以便我可以根据Jira票证中实现的修复将必要的错误自己提供到synapse ClientHandler（或类似的）中？

以下是我收到的警告（我需要是一个错误）以及一些额外的调试信息：

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>

Answer 1

我能够解决，尽管不是以我希望的方式；试图避免改变突触行为：

修改org.apache.synapse.transport.NHTTP.ClientHandler允许我为这种类型的条件抛出一个错误（SOAP fault)，它执行fault序列，在将请求标记为已完成之前执行回滚。（我还希望能够捕获传输异常，如连接失败，以类似的方式执行回滚，因为这是Synapse允许事务消息传递的另一个令人惊讶的漏洞）。我开始怀疑企业中是否有人真的将此用于这种类型的JMS-to-HTTP模式，因为当它实现时，消息泄漏的机会很大，例如，如果endpoint关闭或引发SOAP错误。我已经研究了替代的“存储和转发”模式，但这是异步的，并且要求消息存储队列是可恢复的，并且在中断或故障的情况下在分布式ESB中可用--我的主要消息队列系统已经有了这一点。出于这个原因，我觉得事务性JMS是最好的选择。我是不是漏掉了什么？对于Synapse/WSO2，我是否应该考虑一种更好的模式（理解我需要在几乎零消息丢失的情况下进行同步JMS-to-HTTP/SOAP代理）？