WSO2 ESB：応答でSOAP障害発生時にJMSロールバックを実行する方法

Question

バージョン4.0.3を使用して、現在、例外がある場合にJMSローカルトランザクションを正常にロールバックするフォルトハンドラで定義されたJMS-to-HTTPプロキシに参加するINおよびOUTシーケンスがありますが、フォルトはそうではありませんSOAPFaultがレスポンス（ClientHandlerからのWARNメッセージのみ）に返された場合にスローされるため、元のJMSメッセージが失われます（コミットされます）。 OUTシーケンスの応答を解析してそこに障害を発見すると、ロールバックを実行しても何の効果もありません。なぜなら、OUTシーケンスに到達するまでに、JMSトランザクションがコミットされるからです。

私は は私の問題を解決するために見えるかもしれませんが、この作業を取得するために、このリリースを待っているの贅沢を持っていないWSO2 ESBの次のリリースのために、次の「解決固定」のJIRAチケットを発見した

： https://wso2.org/jira/browse/ESBJAVA-906

を

私の質問は、4.0.3で実装できる回避策はありますか？私は結果などを決定するまで、コミットを実行するスレッドをブロックする方法はありますか？そうでない場合は、Jiraチケットに実装されている修正プログラムごとにシナプス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：ここ

は、いくつかの余分なデバッグ情報と一緒に私が受け取る警告（私はERRORする必要があること）であります}

Answer 1

私は希望通りに解決することができましたが、

org.apache.synapse.transport.nhttp.ClientHandlerを変更すると、このタイプの条件（SOAPフォールト）のフォールトを発生させることができました。これは、フォールトシーケンスを実行して、ロールバックを実行してから要求は完了しました。 （これは、Synapseがトランザクションメッセージの配信を可能にするもう1つの驚くべき点であるため、同様の方法でロールバックを実行する接続障害などのトランスポート例外をトラップできることも期待しています）。私は実際にこのタイプのJMS-to-HTTPパターンをエンタープライズで使用しているのだろうかと思っています。実装されているので、エンドポイントがダウンしているかスローしているなどSOAP障害です。代替の「ストアアンドフォワード」パターンを見ましたが、これは非同期であり、停止や障害の場合にはメッセージストアのキューを回復でき、分散型ESB全体で使用できる必要があります。このような理由から、私はトランザクション型のJMSの方がいいと感じています。何か不足していますか？ Synapse/WSO2（メッセージの損失がゼロに近い同期JMS/HTTP/SOAP仲介を行う必要があることを理解した上で）を考慮する必要があります。