我已经实现了一个 channel 处理程序来处理 http pipelining .我的代码在 github: https://github.com/huntc/netty-http-pipelining
我的问题是围绕我所采用的方法以及它在 Netty 架构的上下文中是否合理。
当我的 HttpPipeliningHandler 接收到上游 HttpRequest 时，它会形成一个新的 OrderedUpstreamMessageEvent 类型的消息事件。此事件也是我的包的一部分，并保留与制定回复消息时所需的请求相关的信息。
当更上游的 channel 处理程序接收到 OrderedUpstreamMessageEvent 时，它通过生成 OrderedDownstreamMessageEvent 来形成回复，例如:
ctx.sendDownstream(new OrderedDownstreamMessageEvent(oue, somemessage));
在哪里
ctx = ChannelHandlerContext instance
oue = OrderedUpstreamMessageEvent instance
somemessage = some message instance to be sent as an http response
您还可以做更多有趣的事情，例如发送分块回复。
这种做法看起来合理吗？它当然有效!在上游处理程序中转换消息事件是否正常/可接受？显然，如果再次转换消息事件，则流水线功能将不起作用。
最佳答案
我快速浏览了一下...一些评论。
1) 您对 PriorityQueue 的访问必须同步，因为下游事件可能会被任何线程触发。
2) nextRequiredSequence 也需要做同样的事情，或者使用 AtomicInteger 应该更好
3) 你想使用 Channel.close()
其他看起来还不错
关于http - Netty http 流水线方法验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15675708/