1

netty（3.6.2.FINAL）とkeep-alive=trueで多くの接続を処理する方法について混乱しています。

サーバー側コネクタとしてnettyクライアントで作業し、別のサービスにhttp呼び出しを行う場合、パフォーマンスのために接続を常に開いたままにしておきます（keep-alive = true）。

問題：開いているチャネルの数には厳しい制限があり、その後、チャネルを開こうとするとクライアントがハングします。なぜ例外がハングしないのですか？これはチャネルタイムアウトに関する設定ですか？

ワーカースレッド内の接続の全体的な管理という観点から、Nettyを理解できないようです。

  • 書き込み/読み取りクライアントのChannelHandler（http要求/応答）をブロックしている場合、接続プールが空であることをどのように検出しますか？

  • ハンドラーはChannelEventを受信できますが、接続プールで使用可能な全体の数については何もありません（とにかく非常に非決定的です）。また、チャネルが開いていない場合、ハンドラーがワーカースレッドで実行されていることを前提として、新しいチャネルを開き始めるのは理にかなっていますか？

  • しかし、接続プールが使い果たされた場合、どのようにして（ハンドラー内の）アイドル状態の接続をクリーンアップしますか？
4

1 に答える 1

0

ハングせずにクライアントブロッキング呼び出しを機能させるには、ハンドラーを完全に分解する必要がありました。この問題は、ハンドラー内でローカルチャネル参照を保持しないことでほとんど解決されました。

ここで、ConnectionInterface＃openConnection（）[新しいChannelFutureを返す]を共有カスタムChannelHandler＃call（ConnectionInterface connectionInterface、HttpRequest request）に渡すだけです。

ハンドラー呼び出しメソッド内でチャネルを開き、channel.write（x）の前にその状態のチェックとともにそのチャネルを渡す方が良いです。！channel.isWritable（）の場合は、チャネルをリサイクルします（たとえば、ConnectionInterfaceなどの新しいクライアント接続から）。 #openConnection（））そして書き込みを再試行してください。チャネルを閉じる必要すらありません（プールで処理されます）。

500スレッド/5000リクエストで実行しただけで、問題なく成功します。

于 2013-02-08T01:31:07.427 に答える