2

最近WSO2 ESBバージョン 4.7 にアップグレードしましたがWindows Server 2008 R2、SOAP リクエストをエンドポイントに単純にプロキシしているときに次のエラーが発生しました。

ハンドラーが矛盾した状態での応答の受信REQUEST_HEAD 

ERROR_CODE : 102511  
ERROR_MESSAGE : Error in Sender  
ERROR_DETAIL : Error in Sender  
ERROR_EXCEPTION : null

問題は、このエラー コードがドキュメントに記載されておらず、例外なく、それをどう解釈するかが明らかでないことです。私が見つけた最も近いコードは SND_INVALID_STATE = 102510 で、ソース コードから判断すると、リクエストに無効なヘッダーが含まれているようです。しかし、すべてのリクエストが失敗するわけではありません。同じリクエストがランダムに成功または失敗する可能性があります。私はフィドラーですべてのリクエストを記録し、それらを再生しました。失敗したものは最終的に成功する可能性があり、その逆も同様です。その前に、ローカル マシン (Windows 7) に新しいバージョンの ESB を展開してテストしましたが、コールド スタートでのみこのようなエラーが発生しました。

これを再現するための最も単純な構成は、Path Through Proxy サービスとアドレス エンドポイントで構成されます。

プロキシ サービスの構成:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="TestEP" transports="http" statistics="disable" trace="enable" startOnLoad="true">
   <target endpoint="TestEP">
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <description/>
</proxy>

アドレス エンドポイントの説明

<endpoint xmlns="http://ws.apache.org/ns/synapse" name="TestEP">
   <address uri="http://mydomain.test/SystemServices.asmx">
     <syn:suspendOnFailure>
       <syn:initialDuration>0</syn:initialDuration>
       <syn:progressionFactor>1.0</syn:progressionFactor>
       <syn:maximumDuration>0</syn:maximumDuration>
     </syn:suspendOnFailure>
   </address>
</endpoint>

他の誰かがこのエラーを経験したことがありますか、または対処方法を知っていますか? 状況についての洞察に感謝します。

更新:
リクエストが失敗する理由は

Expect: 100-continue

リクエスト HTTP ヘッダーのオプション。フィドラーでそれを削除するルールを作成したところ、すべてのクエリが正常に実行されました。WSO2 ESBこのような動作を側で処理する方法があるかどうか、またはヘッダーのこの部分を削除する必要があるかどうかは、まだ明確ではありません。

4

2 に答える 2

2

今日、WSO2 ESB 4.5.1 から 4.7.0 にアップグレードするときに、この問題に遭遇しました。4.5.1 には別の問題があり、それが原因でアップグレードしなければならなかったため、4.7.0 でこの問題に遭遇すると、解決するしかありませんでした。

しばらく考えた後、パフォーマンスを向上させるために 4.6.0 でデフォルトのトランスポートが NHTTP からパススルーに切り替えられたことを思い出しました。4.7.0 は両方の構成で出荷されますが、デフォルトで PT が有効になっています。構成ファイルは axis2 ディレクトリにあります。

${carbon.home}/repository/conf/axis2/

PT 設定ファイルはaxis2_pt.xml. NHTTPのものはaxis2_nhttp.xml. それらを比較して、何が変更されたかを把握できます。幸いなことに、差分はかなりきれいです。

メイン構成ファイルを変更することで、PT から NHTTP に簡単に切り替えることができます。

${carbon.home}/repository/conf/carbon.xml

<ConfigurationFile>の下に要素があります<Axis2Config>。デフォルトのファイルは、axis2.xml多かれ少なかれaxis2_pt.xml. NHTTP に切り替えるには、 を に変更するだけ<ConfigurationFile>です${carbon.home}/repository/conf/axis2/axis2_nhttp.xml。

NHTTP に切り替えると、ESB 4.7.0 が 100 CONTINUE を正しく処理しないという問題が解決しました。具体的には、curl を使用して ESB 経由で別のサービスに PDF をアップロードしようとしていました。PT を使用すると、失敗しました。NHTTPを使用すると、うまくいきました。私の明白な結論は、このシナリオでは PT は単純にバグがあるということです。

私が PT と NHTTP について行った読書から、一方から他方への切り替えの唯一の「公式」の副作用は、特定のシナリオで PT がより高速になることです。ただし、NHTTP は以前から存在しているため、より多くのバグ修正ラウンドを経たという理由だけで、もう少し安定している可能性があります。私は WSO2 ESB の開発に関与していないので、これは確かではありませんが、経験に基づいた推測です。:)

また、Isuru Perera の回答にコメントしたいのですが、必要な評判がないので、https://wso2.org/jira/browse/APIMANAGER-1007 に関して 2 セントを置かなければならないのではないかと心配しています。ここ。この問題は確かに関連しているように見えます-特に今日のcurlに関する私自身の経験に基づいています-しかし、残念ながらWSO2の親切な人々は、最終的にcurlの使用を避けることを推奨する多くのコメントの後、「バグではありません」として問題を解決しました。 「期待どおりに動作する」ため、これは「カールの問題」になります。HTTP 仕様に準拠したリクエストで動作が壊れている IMHO はクライアントの問題ではなく、解決する必要があります。これにより、特定のシナリオ (つまり、クライアントが大きなボディを POST する方法についてもう少し知的な場合) で、PT トランスポートが事実上使用できなくなります。リクエストの本文を解析する必要がないシナリオは、まさに PT トランスポートが設計されたものであり、それが優れているべき場所であるためです。

ああ、これはスタックオーバーフローに関する私の最初の投稿なので、家のルールに違反していたらごめんなさい。私はしばらく受け身の参加者だったので、何も悪いことをしていないことを願っています!

于 2013-08-22T01:30:43.553 に答える