How to detect 'publisher gone away'

Question

I've written a simple publish/subscribe solution using a topic as opposed to a queue paradigm. I start the server, establish a JMS destination, etc., etc., then start the client last (of course). All is well.
Now imagine the server gets stopped for some reason. The client carries on regardless. The problem, though, is that when the server restarts, if it tries sending a message to the client, the client never receives it - presumably because the publish/subscribe connection has been lost ??
Is there a simple way (code snippet ?) of the client detecting that it has lost the connection to the publisher it originally connected to ? Some sort of polling mechanism in a separate thread perhaps ?
Gary Roussak

Answer 1

Thanks all for your attention so far - but I'm still struggling.
I certainly believe all the advice you are generously giving me at the moment, but am not sure how it is relevant to me. I am sure I'm probably being stupid here - but as I say, I'm unfamiliar with the real innards of JMS.
Can I ask you to bear with me whilst I try again to explain the detail of my problem ? And, by the way, the problem is not necessarily about detecting that the JMS provider has gone away, but in getting the subscriber to re-connect successfully.
My JMS provider is J2EE itself, i.e. I'm using J2EE 1.3.1 which has its own classes to implement the JMS API.
My solution is extremely unsophisticated at this stage, based as it is on the SimpleTopicPublisher/SimpleTopicSubscriber example code in a JMS tutorial from earlier this year.
I start the J2EE server and then create a 'Topic' (e.g. 'MyTopic').
I now run up the Publisher client I've created. Think of it as a basic Swing GUI which allows the operator to write a message and transmit it. The Publisher does the usual stuff: establish initial context, establish topic conn factory, lookup the topic name, create connection, create session, create publisher, start connection. And then it sits there waiting for an operator to publish. It is coded to properly clear up all JMS resources when it exits.
Next I run up the Subscriber client. It sits invisibly in the background. Set up is a mirror image of the Publisher except of course it creates a subscriber object instead of a publisher object. And that's it - it idles, waiting for onMessage() to be called. The connection is left permanently started. The only extra is this: instead of using your onException() approach, every five seconds, my Subscriber loops around testing to see if it can still get an initial context and then a factory object - temporary ones, not the same as the ones I've already instantiated. Yes - I know this is a horrible way to do it - but it's all I could think of before you told me about onException(). Let's refer to it as my 'test loop'. If it passes, I know everything is OK, if it fails, I know something has gone wrong. And as far as that goes, it DOES work.
I now publish a message and the Subscriber gets it. No problems.
OK. I now quit my Publisher. The test loop in the Subscriber doesn't fail, but that's not a problem because, if I restart my Publisher some seconds or minutes later and try to publish a message, the Subscriber gets it. So I can suffer the Publisher going down without any impact at all on the Subscriber.
I now quit my Publisher. But then I also follow that with a 'j2ee stop' as well so as to simulate the J2EE server box suffering a major problem. The test loop in the Subscriber now fails: it establishes initial context, but fails to establish a factory. Quite understandable. In the meantime, the test loop continues going round every 5 seconds, trying to set up a new initial context, factory, topic, connection, session, etc. And, whilst J2EE remains down, the loop repeatedly fails. Just what I wanted.
Now I restart J2EE (and also start my Publisher client again). However, the test loop in the Subscriber never recovers, i.e. it always establishes initial context, but never re-instantiates a factory object (and thus cannot do the remaining setup steps either, thus it never receives any more published messages of course). And I can't understand why this is the case - why shouldn't the test loop recover fully if I'm doing all the setup steps again ? If I start a brand new Subscriber client process, it works fine. But what's the difference ? New process id ? new threads ? Am I trying to do something that would not be expected to work ? Why ?
And why is this approach important to me ? Because the user whose PC is running the Subscriber client should not be expected to monitor the health of the client. If the client dies, software should be able automate its restart.
Does this explain the situation more ?