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.
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.