Question

I have a task that has a durable subscriber on a JMS topic and I need to be able to move this task from one host to another.

The task has set its Client ID using:

TopicConnection.setClientID(“MyClient”);

and:

TopicSession.createDurableSubscriber(Topic,
“durable”);

For the relevant instances of TopicConnection, TopicSession and Topic. I’m using client acknowledgement and every message is acknowledged upon successful handling (there were no errors in the example run I posted below).

The task will always have the same Client ID (combination of “MyClient” and “durable”).

However, it appears as if this same Client ID is treated as separate for each host.

So I get the following scenario:

1. Host A is running the subscriber.
2. Messages 1-10 are sent.
3. Host A receives messages 1-10 and shuts down it’s subscriber (closing the connection)
4. Messages 11-20 are sent.
5. Host B sets up a subscriber with (apparently) the same Client ID
6. Messages 21-30 are sent.
7. Host B receives messages 11-30 (and often a few prior messages, seemingly at random)
8. Host B shuts it’s subscriber down
9. Host A sets up it’s subscriber again
10. Host A receives messages 11-30

Am I right in thinking that the host identity is somehow being incorporated into the Client ID under the hood? And is there a way of stopping this happen.

I’m using SwiftMQ, in case this is behaviour is peculiar to that solution.

Answer 1

Ok, we’ve figured out why this is happening.

Each server in our cluster maintains its own JMS router. In SwiftMQ (if not all JMS implementations) durable subscriptions are location dependant. As each router maintains its own list of durable subscriptions, two durable subscriptions on separate routers will be managed separately, even if they have the same Client ID.