重新连接，同时与netty 4保持状态

我正在使用netty 4，并利用

ChannelPipeline

将协议状态管理等内容与编解码器分开（例如）。这真的很好用——我喜欢管道的单线程（如果需要的话）特性

我还想管理断开/重新连接

但是，当“断开连接”时，我想保留那些本来会发送给断开连接的人的消息。 我希望这样做的同时仍然使用netty特性（即在持久化之前仍然使用管道中的处理程序进行编码等）

不过，显然，这个（逻辑）管道的寿命超过了一个通道的寿命（当重新连接发生时，我将使用登录消息中发送的会话名称，并将所有状态拉回到新通道的管道中）

显然，我可以在netty之外完成这一切，但我仍然希望在断开连接时继续使用管道进行编码等。 目前我所能想到的就是使用某种“/dev/null/”样式的（自定义）通道，在我们断开连接时丢弃所有东西，在断开连接时适当地重建管道（我们将在这个“假”死消息通道中切换）并重新连接，以及自定义

EventExecutorGroup

，以保持线程良好（也就是说，固定到“逻辑会话”状态-因此在通道之间移动）。这似乎有点“呃”：

---

在netty 4中，在保持状态和使用管道功能的同时处理断开和重新连接之间的时间段，是否有任何一种现有的“模式”我没有看到文档记录？

听起来您正在努力确保“尽最大努力交付”给客户。我处理类似的事情

上游需要一个连接有队列和通道组的接收器。当客户端连接其中一个接收器时，将创建这些接收器并将其添加到通道组。添加消息时，消息将同时添加到队列和通道组。组中的每个连接都接收这些消息

重新连接时，您（神奇地）将新客户端映射回接收器，并（神奇地）确定其在队列中的位置，然后从队列发送增量，并将其添加到组中。“神奇”部分由你决定

在这段代码中，您确实需要担心并发性，并且您必须担心接收器的手动垃圾收集

我是番石榴的超级粉丝，喜欢TTL和LRU缓存，我在这里使用过它们

更新：

根据下面的说明，您要求动态构建管道并重用处理程序。管道处理程序可以重用，因此这个基本上可以满足您的需要

该图中没有包括正在写入处理程序的外部进程。当ctx被分离并且连接在下游被关闭时，您需要在有状态处理程序中处理到客户机的缓冲。我想你可以用它来做实验

---

希望这能有所帮助。

谢谢-频道组看起来确实很有趣。不太确定他们是我想要的（我可能是误解了！）。看，我想要一个管道来进行各种转换/编码。在管道的某一点上，我坚持。现在，如果连接断开，我想继续转换/编码/持久化-但显然不会尝试发送到死通道。不是单一消息->多通道（这不是重复编码吗？）。因此，在收到“ChannelUnregisted”通知后，除了创建新的虚拟通道外，仍然看不到其他干净的方法：（我想我的意思是，整个管道的工作方式似乎非常丰富和有用：我希望如果您想要切换出底层的“通道”，或者没有（活动的）通道，它不会全部崩溃）通道-同时保持良好的线程模型等。否则，可能会发生的情况是，越来越多的内容在堆栈中“向上”移动一层，而netty仅用于发送预编码（在本例中是持久化的）数据byte buffs…..根据您的澄清更新了答案。是的，听起来更接近我想要的-谢谢，我会试一试。我担心的是，一旦通道关闭，任何写入都会立即失败。记住-即使连接中断，我也需要出站消息通过管道（所以我仍然可以进行所有的编码/持久化）。这就是为什么我怀疑我可能需要一个假通道来在连接断开时运行管道。或者将编解码器/持久性移出netty处理程序-我觉得这将是一个耻辱。ChannelGroup将使您能够从编写器中抽象出通道状态；例如，包含一个活动连接和一个缓冲通道，以便写入到t组将通过这两种方式进行记录；如果实时频道关闭，您将消息存储在缓冲频道中。当您向组添加连接时，您将进入缓冲频道，并要求其消息通过重新连接的实时频道运行。