3

カスタム プロトコルを使用する Netty(3.5.11) ベースの IM サーバーを開発しました。

以下は、ハンドラーがパイプラインに追加される順序です。

objChannelPipeline.addLast("nettyLoggingHandler", objFrameworkLoggingHandler);
objChannelPipeline.addLast("ipFilter", objCustomIPFilterHandler);
objChannelPipeline.addLast("idleHandler", objIdleStateHandler);
objChannelPipeline.addLast("loggingHandler", objLoggingHandler);
objChannelPipeline.addLast("frameDecoder",objDelimiterBasedFrameDecoder);
objChannelPipeline.addLast("messageDecoder", new CustomProtocolDecoderHandler());
objChannelPipeline.addLast("groupOrder", executionHandler);
objChannelPipeline.addLast("ProtocolMultiplexer", objRegistrationHandler);

「ProtocolMultiPlexer」ハンドラは、クライアントから取得した登録メッセージからプロトコルを見つけた後、適切な「ProtocolHandler」に置き換えられます。

ipFilterHandler は、ブラックリストに登録された IP を含む MYSQL データベースのテーブルを調べ、リモート IP からの接続を処理するかどうかを決定します。

問題 : ランダムな数日ごとに、サーバーはメッセージの処理を停止します。この問題は、負荷テストを実行し、mysql サーバーへのすべての接続を強制終了することで再現できます。すべての MYSQL プロセスが強制終了されると、ボス スレッドを除くすべての netty スレッドがハングしているように見えました。サーバーは接続要求を受け入れていましたが、メッセージの処理は行われませんでした。MYSQL の「connectTimeout」と「socketTimeout」の値を追加していないことが判明したとき、問題は解決したと考えました。これらの値を追加した後、負荷がかかっているすべての MYSQL プロセスを強制終了してテストを繰り返してみましたが、ハング状態に入るスレッドは見つかりませんでした。

上記の変更を加えたサーバーを本番環境にデプロイした後、同様のエラーが発生しましたが、今回は他のすべての「Netty」スレッドとともにボス スレッドもハング状態になりました。機能している唯一のスレッドは、DBPool ( http://www.snaq.net/java/DBPool/ ) からのクリーン スレッドです。Netty スレッドは何もログに記録しておらず、すべてのスレッドがハングしているように見えます。スレッドダンプを取得できませんでした。どんな助けもかなりのものです

ありがとう

4

1 に答える 1