プロキシの AsyncContext や ning AsyncHttpClient など、多くのコンポーネントを備えたクライアント/サーバー Web アプリがあり、タイムアウトと再試行 (および startAsync/complete) がどのように機能するかを理解しようとしています。これが完全な構造です（簡略化）...
アクション (ボタンのクリックなど) に応答して、アプリケーション サーバー上のサーブレットを呼び出す GWT 2.7 アプリ。このサーブレットは、プロキシ サーブレットを経由して別のホストに移動し、長時間実行されるタスクを実行します。開発では、組み込みの jetty サーバーを使用して GWT アプリを実行/デバッグします。本番環境では、war を tomcat7 にデプロイします。
最初のサーブレットは、RestEasy 3.0.8 (および ApacheHttpClient4Executor) を使用して、プロキシ サーブレットを通過する呼び出しを作成します。ここでは、ning AsyncHttpClient 1.7.5、startAsync/complete、および AsyncHandler を使用して、リモート ホスト (RestEasy も使用) 上のサーバーを呼び出しています。これは、現在私が相談できない他の誰かによって設定されました。
complete() をいつ呼び出すか、または再試行を停止/有効にする方法がわかりません。大きな問題の 2 つは、(コンテキスト タイムアウトのプロキシ内で、または [AsyncResponse] がタイムアウトしたリモート サーバーへの呼び出しのいずれかで) タイムアウトの前後で complete() すると、IllegalStateException の (IDLE,initial) が頻繁に発生することです。そして... Jettyは、コンテキストタイムアウトが発生したときに(プロキシで)リクエストを完全に再起動するように見えます.入力ストリームを使用すると、2 回目/再試行では同じ入力ストリームが使用され、その結果、リモート サーバーは 2 回目の呼び出しで EOF 例外をスローします (読み取るバイトが残っていないため)。一方、受信した最初の呼び出しは引き続き処理されます。
私が試したこと/学んだこと...
RestEasy/ApacheHttpClient4Executor 呼び出しは決してタイムアウトしないようです (したがって、再試行の設定は重要ではありません) - 呼び出しの反対側で何が起こるかに基づいて、成功または失敗します (そして一見永久に待機します)...例...
HttpParams パラメータ = client.getParams(); HttpConnectionParams.setConnectionTimeout(params, 5000); HttpConnectionParams.setSoTimeout(params, 5000);
((AbstractHttpClient) クライアント).setHttpRequestRetryHandler(新しい DefaultHttpRequestRetryHandler(3, true));
AsyncHttpClientConfig の setConnectionTimeoutInMs() はまったく何もしないようです (サーバー接続を確立するのにかかる時間だけでない限り - 完全な要求時間が含まれていると思いました)
タイムアウトで startAsync を実行してリクエストを実行すると、リクエストが完了する前にタイムアウトした場合、コンテキスト リスナーは onTimeout イベントを取得し、Jetty はリクエスト全体を再起動します (リスナーも onStartAsync イベントを取得します)。同じ文脈）。Tomcat はこれを行いません。別の人が同じことに遭遇したようですが、返信はありませんでした...
http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg02269.html
onTimeout で complete() を呼び出すと、2 番目のリクエストが停止します。代わりに onStartAsync で complete() を呼び出すと、奇妙な結果が得られます (2 番目の呼び出しはまだ発生し、AsyncHandler の onComplete はある時点で呼び出されますが、onThrowable が呼び出される [??] という結果になる IllegalStateException がスローされます)。
この構成で AsyncHttpClient に再試行を設定しても、何もしないようです (asyncTimeout、requestTimeout などの組み合わせでのみ発生する場合を除きます。まだ把握していません)。
応答ステータスを (たとえば 408 に) 設定すると、まれに機能するように見えますが、多くの場合、サーバーで EOF 例外が発生して 500 が生成され、私がそれについて多くのことを行うことができずにクライアントに返されるため、機能しません (最初の呼び出しはまだ進行中です。これが 2 回目の呼び出しであること (失敗したこと以外) や、タイムアウトが原因で発生したことなどはわかりません)
AsyncContext のメソッドから収集できる情報はほとんどありません。リフレクションを使用して、使用できるデータを取得できますが、それがなければ...再試行されたかどうかをどのように知ることができますか? complete() を呼び出すかどうかを判断するために、どのような状態かを知るにはどうすればよいですか? などなど
AsyncContext (et al) オンラインに関する良い情報はほとんどないようで、javadoc が混乱しており、SO に関する小さな/孤立した修正の提案しかありません。これまでに出会った中で最高のものはこれです：
結論: AsynContext/AsyncHandler がどのように機能するか、および/またはそれを適切に使用する方法、および/またはここで見ているものを理解するのに役立つ方法について、誰かが説明したり、良いドキュメントを教えてくれたりできますか? ありがとうございました！