如何判断 java.jms.TopicSubscriber 何时失去与消息代理的连接？
我今天正在尝试使用 TopicSubscriber 对象（使用 ActiveMQ 作为我的消息代理和 JMS 提供程序）。我发现，如果我在建立连接后启动同步接收（超时 2 毫秒），并且在建立连接和启动第一次接收之间停止 ActiveMQ，则会引发异常。但是，如果我进行连接，然后成功接收，然后停止代理，然后进行第二次接收，那么我不会在该接收上抛出异常，而是始终收到一条空消息 - 没有迹象表明连接到即使等了几个小时，经纪人也迷路了。然后，重新启动 ActiveMQ 后，除非我的程序关闭并重新打开与它的连接，否则它的任何接收都不会工作。
我知道我可以围绕这个进行编码，但我想知道我是否错过了一些关于如何判断我的连接是否丢失的东西 - 请告诉我是否有办法，或者这是否只是一个“功能”我需要围绕 ActiveMQ 的 JMS 实现进行编码。
I was experimenting with a TopicSubscriber object today (with ActiveMQ as my message broker and JMS provider). I found that if I initiated a synchronous receive (with a 2 ms timeout) after establishing a connection, that an exception would be thrown if I stopped ActiveMQ in between establishing the connection to it and initiating the first receive. But if I did the connect, then a successful receive, then stopped the broker, and then did a second receive, that instead of having an exception thrown on that receive, I consistently just got a null message back - no indication that the connection to the broker was lost - even after waiting a couple of hours. And then, after restarting ActiveMQ, unless my program closed and reopened its connection to it, none of its receives would work.
I know I can code around this, but I'm wondering if I've missed something as far as knowing how to tell if my connection is lost - please tell me if there's a way, or if this is just a "feature" of ActiveMQ's JMS implementation that I need to code around.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我使用 ActiveMQ 已经有几年了，尽管使用的是队列而不是主题，但我从未见过这样的行为。我也许可以看到，如果连接中断而代理无法正确断开消费者的连接，那么消费者可能不会立即意识到问题。我不确定，但我认为 ActiveMQ 消费者在建立连接后不会与代理进行太多对话。他们只是等待消息传递。尽管如此，我还是希望有某种心跳，并且在 OpenWire Format 页面< /a>，它确实意味着 OpenWire 有一个默认的 30 秒空闲时间。尝试进行一些网络监控以查看消费者是否尝试发送任何内容。如果它确实如此并且仍然没有意识到连接已断开，那么就会出现一些可疑的情况。否则，这可能只是找到正确方法来保持活动状态的问题。 TCPTransport keepalive 设置也可能值得研究。
I've been using ActiveMQ for a few years, though with queues and not topics, and I've never seen behavior like that. I could see, perhaps, if a connection were interrupted without the broker being able to properly disconnect a consumer, that the consumer might not be aware immediately about the problem. I don't know for sure, but I think that ActiveMQ consumers don't do much talking to the broker after the connection is established. They just wait for messages to be delivered. Still, I'd expect there to be some kind of heartbeat, and on the OpenWire Format page, it does imply that OpenWire has a default 30-second idle time on it. Try doing some network monitoring to see if the consumer ever tries to send anything. If it does and still doesn't recognize that the connection is dead, then there's something fishy going on. Otherwise, it's probably just a matter of finding the right way to do a keep-alive. The TCPTransport keepalive etting might be good to investigate, too.