apache mina 中的死会话
我们有一个基于 apache mina 的 GPRS 网关（服务器）。有时，通常当连接从客户端被残酷地终止时，即，电源线被拔掉或任何其他异常关闭或网络出现问题时，它不会在服务器端被删除或关闭。它保持在那里，处于空闲状态，因为我不知道多久（可能是永远）。 有时我们在关闭服务器时遇到问题，MINA 花费了太多时间，有时我们最终不得不终止它。我们怀疑此问题与死连接问题有关。
其实，这种死联系是有道理的。由于连接被残酷地关闭，并且 mina 没有办法检查它（这就是 tcp 会话的工作原理）。 作为一种解决方法，我们设计了一个解决方案，如果会话保持空闲（读取和写入）状态达 30 分钟（或任何可配置的时间），我们将关闭会话。我们不喜欢它有两个原因：
1-看起来不太好。
2-另外，我们有一条规则，即客户端与服务器建立持久连接。因此，设置“空闲超时”有点困难，因为我们不能关闭任何已空闲 x 分钟/小时的会话，因为它可能是有效的连接。
那么，有没有更好、更安全（在我们的例子中）的方法来检测和清理 MINA 中的这些死连接？
We have a apache mina based GPRS gateway(server). Sometimes, usually when the connection is terminated from client side brutally i.e, power cable unplugged or any other unusual shutdown or some problem with network, it is not removed or closed at server side. It remain there, in idle state, for I don,t know how long( may be forever).
At times we face issues while shutting the server down, MINA take too much time and at times we have to kill it eventually. We suspect that this issue is related to dead connection problem.
Actually, this dead connection make sense. Since the connection is closed brutally and mina don't have a way to check it (that's how tcp session works).
We as a workaround, devised a solution that we will close session if it remain idle (both read and write) for let say 30 min(or any configurable time). Which we do not like for 2 reasons:
1- It doesn't look nice.
2- Plus we have a rule that client make a persistent connection with the server. So, it's a bit difficult to set an 'idle timeout' as we can't just close any session which has been idle for x min/hrs as it can be a valid connection.
So, is there any nicer and more safer (in our case) way to detect and clean these dead connection in MINA?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这两种情况下，长时间不活动连接和丢失连接 - 通道中没有活动应导致在 OSI 模型。
例如，您的防火墙/路由器/服务器可能会在 10 分钟内超时非活动连接条目，那么您的应用程序层连接也应该在 10 分钟后执行此操作 - 等待更多是没有意义的。
为了防止静默连接超时，应引入保持活动协议。
它可能是 ping（不完全是 ICMP）或其他形式的周期性无操作通信。
当对等方处于活动状态时，它应该做出响应，从而刷新所有网络层上的超时倒计时。由于超时或层信令连接断开而导致尝试失败后，您可以假设您的应用程序层连接也已断开。
In both cases long not active connection and lost connection - having no activity in channel should result in timeout after configured time in every layer of OSI model.
E.g. you firewall/router/server may timeout inactive connection entry in 10 minutes, then you application layer connection should also do that after 10 minutes - waiting more makes no sense.
To prevent silent connections from timeout keep-alive protocol should be introduced.
It may be ping (not exactly ICMP) or other form of periodic no-operation communication.
When peer is alive it should respond and thus refresh timeout countdown on all network layers. After failed attempt caused by timeout or layer signaling broken connection you can assume that your application layer connection is also broken.