1

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

次の WSO2 ESB の次のリリース用の「解決済みの修正済み」Jira チケットを見つけました。これで問題が解決したように見えますが、このリリースを待って問題が解決するまで待つ余裕はありません: https://wso2.org/jira /ブラウズ/ESBJAVA-906

私の質問は、4.0.3 で実装できる回避策はありますか? 結果などを判断できるまで、コミットを実行しているスレッドをブロックする方法はありますか? そうでない場合は、新しいリリースのソース コードを参照して、Jira チケットに実装されている修正に従ってシナプス ClientHandler (または同様のもの) に必要な障害を自分で提供できますか?

これは、いくつかの追加のデバッグ情報とともに、私が受け取った警告 (エラーである必要があること) です。

TID: [] [WSO2 ESB] [2012-04-18 17:18:23,786] INFO {org.apache.synapse.core.axis2.TimeoutHandler} - このエンジンは、タイムアウトに関係なく、86400 秒後にすべてのコールバックを期限切れにしますアクション、指定またはオプションのタイムアウト {org.apache.synapse.core.axis2.TimeoutHandler} の後
TID: [] [WSO2 ESB] [2012-04-18 17:18:23,790] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} - コールバックが追加されました。待機中のコールバックの合計: 1 {org.apache.synapse.core.axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,006] 警告 {org.apache.synapse.transport.nhttp.ClientHandler} - 内部サーバー エラーを受け取りました: 内部サーバー エラー: 127.0.0.1: 8080 要求の場合: Axis2Request [メッセージ ID: urn:uuid:6322ced4-801f-40fe-a3a7-bb4019b02cdb] [完了ステータス: true] [送信完了ステータス: true] {org.apache.synapse.transport.nhttp.ClientHandler}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,015] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} - 要求メッセージ ID のコールバックが削除されました: urn:uuid:6322ced4-801f- 40fe-a3a7-bb4019b02cdb. 保留中のコールバック数: 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 が非同期応答メッセージ {org.apache.synapse.core. axis2.SynapseCallbackReceiver}
TID: [] [WSO2 ESB] [2012-04-18 17:18:24,016] DEBUG {org.apache.synapse.core.axis2.SynapseCallbackReceiver} - 受信先: 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} - 本体:

<?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}

4

1 に答える 1

0

私が望んでいた方法ではありませんでしたが、解決することができました。シナプスの動作を変更することを避けようとしていました:

org.apache.synapse.transport.nhttp.ClientHandler を変更すると、リクエストを完了としてマークする前に、ロールバックを実行するフォールト シーケンスを実行するこのタイプの条件 (SOAP フォールト) に対してフォールトをスローすることができました。(また、接続障害などのトランスポート例外をトラップして、同様の方法でロールバックを実行できることを望んでいます。これは、Synapse のトランザクション メッセージ配信を可能にする機能のもう 1 つの驚くべき穴であるためです)。企業でこのタイプの JMS から HTTP へのパターンにこれを実際に使用している人がいるのだろうかと私は考え始めています。これが実装されると、たとえばエンドポイントがダウンしたりスローされたりした場合など、メッセージが漏えいする可能性が高くなるからです。 SOAP 障害。代替の「ストアアンドフォワード」を見てきました パターンですが、これは非同期であり、障害や障害が発生した場合に分散 ESB 間でメッセージ ストア キューを回復可能にして使用できるようにする必要があります。このため、トランザクション JMS が進むべき道だと思います。何か不足していますか？Synapse/WSO2 で検討すべきより良いパターンはありますか? 何か不足していますか？Synapse/WSO2 で検討すべきより良いパターンはありますか? 何か不足していますか？Synapse/WSO2 で検討すべきより良いパターンはありますか?

于 2012-04-20T19:39:11.490 に答える