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

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

我找到了下一版本WSO2 ESB的以下已解决的固定Jira问题，它似乎解决了我的问题，但没有等待此版本工作的奢侈：

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

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

soap：服务器 org.apache.cxf.service.factory.ServiceConstructionException:未能创建服务。 {org.apache.synapse.core.axis2.SynapseCallbackReceiver}

---

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

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

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 :