使用版本4.0.3,我当前有一个IN和OUT序列参与一个JMS-to-HTTP代理,该代理定义了一个故障处理程序,如果有异常,它将成功回滚JMS本地事务,但是故障是如果在响应中返回SOAPFault(仅来自ClientHandler的WARN消息),则不会抛出,因此我丢失了原始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>
{org.apache.synapse.core.axis2.SynapseCallbackReceiver}
答案 0 :(得分:0)
我能够解决,虽然不是我希望的方式;试图避免修改Synapse行为:
更改org.apache.synapse.transport.nhttp.ClientHandler允许我针对此类条件(SOAP错误)抛出错误,该错误执行执行回滚的错误序列,然后将请求标记为已完成。 (我也希望我能以类似的方式捕获传输异常,例如连接失败以执行回滚,因为这是Synapse允许交易消息传递的另一个令人惊讶的漏洞)。我开始怀疑是否有人真的在企业中使用这种类型的JMS-to-HTTP模式,因为实现时,消息泄漏的机会很大,例如,如果端点关闭或丢失一个SOAP错误。我已经查看了备用的“存储转发”模式,但这是异步的,并且要求消息存储队列在中断或失败的情况下可以在分布式ESB中恢复并可用 - 我已经将其与主消息队列系统一起使用了。出于这个原因,我觉得事务性JMS是要走的路。我错过了什么吗?是否有一个更好的模式我应该考虑使用Synapse / WSO2(理解我需要进行同步JMS到HTTP / SOAP代理,消息丢失几乎为零)?