0

現在、Jersey 1.0 を使用しており、2.0 に切り替えようとしています。REST リクエストの場合、1 ~ 2 秒以上続く場合があります。次のパターンを使用します。

  1. クライアントが GET または PUT を呼び出す
  2. サーバーがポーリング URL をクライアントに返す
  3. クライアントは、完成したリソースへのリダイレクトを取得するまで URL をポーリングします。

かなり標準的で簡単です。しかし、Jersey 2.0 には AsyncResponse 機能があることに気付きました。しかし、これはワイヤに変更を加えることなく行われたようです。つまり、サーバーが要求を非同期的に処理している間、クライアントは引き続き結果をブロックします。

それで、これは何が良いですか?1 秒を超える呼び出しに対する現在の非同期アプローチの代わりに使用する必要がありますか? それとも、ほんの数百ミリ秒の呼び出しのためにサーバー上で接続を解放しておくだけですか?

サーバーをできるだけスケーラブルにしたいのですが、現在使用しているアプローチはクライアントにとって面倒な場合があります。AsyncResponse は非常にシンプルに見えますが、非常に短い接続時間を必要とする heroku サービスのようなものでどのように機能するかはわかりません。

4

1 に答える 1

0

AsyncResponse はおそらく、スレッド プール リソースの観点から、標準の標準リクエストに対して Web アプリ サーバー内でより多くのスケーラビリティを提供しますが、接続での読み取り時に引き続きブロックされるクライアント エクスペリエンスについては何も変わらないと思います。したがって、クライアント側からポーリング ソリューションを既に実装している場合、これは私見に何の価値も追加しません。

于 2013-07-11T21:22:02.640 に答える