Can durable subscriptions survive client restart?

Question

If I use durable subscription, can I restart my client and resubscribe without loosing any messages? (Assuming, my client does not unsubscribe in any way. Lets say it just crashes).

Let me clarify. JMS 1.1 Spec says the following:

9.3.3.2 Reconnecting to a Topic using a Durable Subscription

/* Reconnect to a durable subscription */
session.createDurableSubscriber(newsFeedTopic, "mySubscription");

However, there are some important restrictions to be aware of:

• The client must be attached to the same Connection.
• The Destination and subscription name must be the same.
• If a message selector was specified, it must also be the same.

That "same Connection" part interests me. It is not clear what "same" means in this context.

Answer 1

If there is no active subscriber for a durable subscription, JMS retains the subscription's messages until they are received by the subscriber, or until they expire, or until the durable subscription is deleted. This enables subscriber applications to operate disconnected from the JMS provider for periods of time, and then reconnect to the provider and process messages that were published during their absence.

Answer 2

In the spec, take a look at 4.3 where it mentions that the Connection object can contain a unique client identifier and 4.3.2 which states...

The purpose of the client identifier is to associate a connection and its objects with a state maintained on behalf of the client by a provider. By definition, the client state identified by a client identifier can be ‘in use’ by only one client at a time. A JMS provider must prevent concurrently executing clients from using it.

So the intent here is that the durable subscription contains a unique identifier so that when the app resubscribes it can be attached to the correct state-store where messages have been queued up in its absence. Since the preferred way of doing this is to code the identifier in a client-specific connection object, the spec directs you to reconnect using the same connection but in this case that means the administered object not the same connection handle (to use the WMQ terminology).

Of course, you don't need an administered object, the app can generate a connection dynamically. In that case you'd need to arrange for it to use the same client identifier for successive suscriptions.