1

独自のフレーム デコーダーを実装して、UDP ソケット経由で受信したバイトを (NioDatagramChannelFactory と ConnectionlessBootstrap を使用して) プロトコルに従って解析しました。メッセージの受信中にサーバーで何が起こっているかを追跡するために、デコーダーの各コールバック メソッドにトレース ログを追加しました。

サーバーが受信するほぼすべてのメッセージで、メソッド channelInterestChanged() でイベント「channelInterestChanged」が 2 回受信されていることがわかります。イベントの値は、最初は 0 (OP_NONE)、次に 1 (OP_READ) です。

これに関するドキュメントを読みましたが、なぜこのようなイベントが発生するのかまだよくわかりません。最初に確認したのは、受信バッファー (またはセレクター キュー) がいっぱいだったからですが、サーバーは "messageReceived" イベント (decode() メソッドが呼び出される前) とすべてのメッセージを受け取るのと同じ回数、このイベントを受け取ります。 /frames は期待どおりに正しくデコードされます。メッセージが欠落している場合、イベントはまったく表示されません。この場合、おそらくデータグラム ソケットの受信バッファがいっぱいになっていることが原因です。しかし、この受信バッファーを増やしても、引き続きこれらのイベントが表示され、メッセージが失われます。

したがって、受信したメッセージごとに、サーバーが2つの「channelInterestChanged」も受信する理由が不思議です。1つはOP_NONE値で、もう1つはOP_READ値です。チャネル パイプラインでは、私のフレーム デコーダーの後に、ExecutionHandler と別のビジネス固有のハンドラー (JMS メッセージを ActiveMQ インスタンスに送信する) があることにも注意してください。

私のためのアイデアや説明はありますか？

ありがとうございました。

4

1 に答える 1

0

DownStreamChannelStateEvent がハンドラーから起動されると (例: を呼び出す) channel.setReadable()、channel.setWriteable()イベントはチャンネルの nio セレクター キーの関連するオプションを変更しNioDatagramWorker、その後、UpstreamChannelStateEvent変更されたオプション (つまりOP_READまたはOP_NONE)で起動されます。

フレーム デコーダー ハンドラーが受信UpstreamChannelStateEventsするのは、パイプライン内の他のハンドラーがチャネルの読み取り対象オプションを変更しているためです (channel.setReadable/setWriteable を呼び出す目的はOutOfMemoryError、アプリケーションで輻輳を回避するために読み取り/書き込みを調整することです)。

パイプラインに (使用されているチャネル メモリのサイズを監視する) がある場合 、チャネルがメッセージを受信する速度が速すぎると、いつでもMemoryAwareThreadPoolExecutor呼び出して読み取りを一時停止または再開できます。channel.setReadable()最適な maxChannelMemorySize、maxTotalMemorySize で MATPE インスタンスを構成するか、0 に設定して無効にする必要がある場合があります。

于 2012-03-17T08:35:17.527 に答える