Я продолжаю в своем стремлении понять внутренности Нетти.
В ChannelPipeline очевидно, что цель состоит в том, чтобы иметь ChannelHandler с, которые в основном не знают друг друга. Обработчики входящих событий реагируют на события и запускают другие события, перезапуская все, что они не полностью потребляют или обрабатывают иначе. Хорошо.
Одна из вещей, которую может сделать обработчик, это вызвать channelHandlerContext.read(). (Предположим, для этого примера, что автоматическое чтение отключено.)
В конечном счете, конечно, в конечном итоге в результате будет запущено событие channelReadComplete (очевидно, после того, как все обработчики получат свои channelRead методы вызваны и чтение действительно завершено).
Шаблон, который я видел, заключается в том, что обработчик для обработки этого события channelReadComplete должен сначала переслать это событие (channelHandlerContext.fireChannelReadComplete()), а затем запроситьчитать (обычно, если авто-чтение отключено) (channelHandlerContext.read()). HttpContentDecoder - произвольно выбранный пример такого шаблона, который делает именно это .
Предположим, я следую тому же шаблону в обработчике, который идет "после" HttpContentDecoder. Не будет ли так, что два read() запроса теперь будут поставлены в очередь? В идеале, должен быть только один, верно, как это было бы в случае, если авточитание было включено?
В более общем случае: в конвейере обработчиков n , которые делают это,не приведет ли это к n read() запросам, где на самом деле требуется только один?