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