我正在使用netty 4并使用ChannelPipeline来保持协议状态管理与编解码器分离（例如）。这非常有效 - 我喜欢单线程（当你需要它时）管道的性质。
我还想管理断开连接/重新连接。
但是 - 当'断开'时 - 我想要保留原本会被发送给断开连接的家伙的消息。 我想这样做，同时仍然使用netty功能（即仍然使用管道中的处理程序在持久化之前进行编码等）。
显然，这个（逻辑）管道超过了一个通道的生命周期（当重新连接发生时，我将使用在登录消息中发送的会话名称并将所有状态拉回到新通道的管道中）。
显然我可以在netty之外完成所有操作 - 但我仍然希望在断开连接时继续使用管道进行编码等。
我现在所能想到的只是使用某种'/ dev / null /'样式（自定义）通道，它在我们断开连接时丢弃所有内容，并在断开连接时适当重建管道（我们切换到的地方）这个'假的'死消息通道）并重新连接，并且自定义EventExecutorGroup以保持线程良好（即固定到'逻辑会话'状态 - 因此在通道到通道之间移动）。这似乎有点“呃”：）
是否有任何现有的'模式'我没有看到记录在交换断开和＆amp;之间的时间段。重新连接，同时保持netty 4中的状态和管道功能的使用？
答案 0 :(得分：0)
听起来你正在努力确保向客户提供“尽力交付”。我处理类似的事情。
在上游，您需要一个带有队列和附加通道组的接收器。当客户端连接时，会创建其中一个接收器，并将它们添加到通道组。添加消息后，它们将添加到队列中并写入通道组。组中的每个连接都会收到这些消息。
在重新连接时，您（神奇地）将新客户端映射回接收器，并（神奇地）确定其在队列中的位置，并从队列中发送增量，并将其添加到组中。 “魔法”部分取决于你。
您需要担心此代码中的并发性，并且您必须担心接收器的手动垃圾收集。
我是Guava的忠实粉丝，用于TTL和LRU缓存，我在这种情况下使用它们。
<强>更新
根据以下说明，您要求动态构建管道并重用处理程序。管道处理程序可以重复使用，因此此sequence diagram 应该基本上可以执行您想要的操作。
该图中未包含的是写入处理程序的外部进程。分离ctx并关闭连接时，您需要在状态处理程序中处理对客户端的缓冲。我认为你可以试验的确切机制。
希望这有帮助。