2

Netty 4は、「パイプラインの最後に到達した1つのインバウンドメッセージを破棄しました。パイプライン構成を確認してください」という警告を発行します。どういう意味ですか？どのように処理する必要がありますか？（以前は、受け入れられた回答に従って解決されるまでここで再現されていましたが、それが何を意味し、パイプラインがどのように機能するかについての一般的な説明が必要です）

Nettyフィードバックを最大限に活用しようとすると、クライアント側のパイプラインは次のように設定されます。

pipeline.addLast("logger", new LoggingHandler(LogLevel.TRACE))
pipeline.addLast("HttpRequestEncoder", new HttpClientCodec)
pipeline.addLast("handler", new myHandler)

Nettyによって2つのhttpメッセージが送信され、サーバー側で正常に受信および確認されている間に、クライアント側でログオンしているのは次のとおりです。

12 [main] DEBUG io.netty.util.internal.InternalLoggerFactory  - Using Log4J as the default logging framework
164 [nioEventLoopGroup-1-2] DEBUG io.netty.channel.nio.SelectorUtil  - Using select timeout of 500
164 [nioEventLoopGroup-1-2] DEBUG io.netty.channel.nio.SelectorUtil  - Epoll-bug workaround enabled = false
229 [nioEventLoopGroup-1-2] WARN io.netty.channel.DefaultChannelPipeline  - Discarded 1 inbound message(s) that reached at the end of the pipeline. Please check your pipeline configuration.
230 [nioEventLoopGroup-1-2] WARN io.netty.channel.DefaultChannelPipeline  - Discarded 1 inbound message(s) that reached at the end of the pipeline. Please check your pipeline configuration.

ロギングは最小限に設定されていますが、次のようになります。

BasicConfigurator.configure       
InternalLoggerFactory.setDefaultFactory(new Log4JLoggerFactory)
4

4 に答える 4

5

Netty 4では、サーバーまたはクライアントで使用されるHTTPデコーダーは、常に1つのHTTPメッセージごとに複数のメッセージオブジェクトを生成します。

1       * HttpRequest / HttpResponse
0 - n   * HttpContent
1       * LastHttpContent

言い換えると：

  • サーバーは1つのHttpRequest、0-nのHttpContent（s）、および1つのHttpLastContentを受け取ります
  • クライアントは、1つのHttpResponse、0-nのHttpContent（s）、および1つのHttpLastContentを受け取ります。

したがって、ハンドラーがHttpRequest / HttpResponseのみを消費する場合、他のメッセージはパイプラインの最後に到達します。それらを消費する必要があります。これは、パイプラインが「誤って構成されている」場所です。

OTOHパイプラインにHttpObjectAggregatorを追加して、代わりにFullHttpRequest/FullHttpResponseメッセージが生成されるようにすることができます。

pipeline.addLast( "http-aggregator", new HttpObjectAggregator( MAX_SIZE ) );

ただし、ハンドラーが呼び出される前に、bodyエンティティを含む要求または応答全体がロードされることを意味します。たぶんあなたはそれを望まないでしょう、YMMV。

于 2013-03-22T16:36:59.400 に答える
4

Netty 4は、作成したパイプラインに最後のハンドラーを自動的に1つ追加します。イベントがこの最後のハンドラーに到達すると、メッセージを通過します。最後のインバウンドハンドラーは、コンテキストイベントを発生させないようにする必要があります。

これを削除します：ctx.fireChannelRead（msg）;

于 2014-11-24T20:31:26.530 に答える
2

@eskatosは正しいです。たとえば、タイプマッチングに基づくパイプラインのハンドラー処理はSimpleChannelInboundHandler<HttpContent>HttpContentを処理するだけです。まだHttpReponseを処理していない場合（SimpleChannelInboundHandler<HttpReponse>パイプラインに追加）、Nettyは警告します：Content-Length：<length>の末尾に到達しましたパイプライン。パイプライン構成を確認してください。

したがって、解決策は、対応するものChannelInboundHandler/ChannelOutboundHandlerをパイプラインに追加することです。

ただし、最初に入力されたハンドラーが欠落しているものを知る必要があります。DefaultChannelPipelineのchannelReadメソッドを見つけてデバッグし、メッセージが欠落しているものを含むmsg.content（）。toString（）を取得します。

もう1つ、@Norman Maurerはデバッグログを有効にするために言及しましたが、channelReadメソッドはメッセージのコンテンツの内容をログに記録しないため、機能していません。

以下のDefaultChannelPipelineのchannelReadメソッド（Netty 4.1）：

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        try {
            logger.debug(
                    "Discarded inbound message {} that reached at the tail of the pipeline. " +
                            "Please check your pipeline configuration.", msg);
        } finally {
            ReferenceCountUtil.release(msg);
        }
    }
于 2015-08-26T06:47:52.187 に答える
1

これは、メッセージがパイプラインの最後に到達し、「インバウンドハンドラー」がそれを処理できなかったことを意味します。これはほとんどの場合、ChannelPipelineの「構成」エラーを示しています。

于 2013-03-06T19:41:05.380 に答える