我们正在使用 spring-integration 进行 TCP 通信，并查看在该连接上的消息之前接收到 TcpConnectionCloseEvent 的行为。
这是一个问题，因为我们使用 TCP 事件来跟踪连接等，并且当我们需要接受我们认为已关闭的连接上的消息时，它会产生更复杂的场景。
反之亦然 - 有时我们会收到一条我们还不知道已打开的连接的消息。
有什么方法可以确保这些事件的正确顺序，即使它们本质上是异步的？
（感谢 Gary 在 stackoverflow 上的精彩回答）。
【问题讨论】：
嗯……
在服务器端，open 事件由接受新连接的线程而不是连接本身发布。虽然我们可以在那里做一些事情，但在使用 NIO 时仍然不是万无一失的，因为那里的线程模型要复杂得多，即使连接本身发布事件也无法保证顺序。
老实说，我们没有预料到事件会以这种方式使用 - 主要驱动因素（对于打开事件）是允许应用程序检测新连接而无需客户端实际发送任何内容（只是连接） - 允许服务器端应用程序接受新连接，获取连接 ID 的句柄，以便发送欢迎消息。
一种解决方法可能是使用事件入站通道适配器和<delayer/> 来延迟将事件传递到您的应用程序（在关闭的情况下）。
对于公开活动的延迟交付，我真的没有很好的解决方案；也许只是将“新”连接的入站消息视为“打开”事件（例如，当您在处理消息的线程上检测到这种情况时发布您自己的打开事件，并忽略“真实”事件）。
【讨论】：