Durable subscription client ID in RabbitMQ JMS

[mprah...@gmail.com]

To implement durable subscribers in the RabbitMQ JMS Client, one has to declare a queue as durable and use routing keys to receive messages from the producer. Everything works fine, and this is how I declare the subscription - 

messageConsumer = session.createDurableSubscriber(topic, "DurableJMSSubscriber1", "", false);

Now, the queues are separately created for each subscriber based on the name I assign. 

However, in plain JMS, you also had to assign a client ID on the connection to distinguish different durable subscribers and it would throw an error in case of a duplicate ID. 

1) In RabbitMQ JMS, I can still set a clientID for a connection, but it doesn't seem to do anything. Does it serve any purpose?

2) Is there any function or configuration that checks for the same subscription name in session.createDurableSubscriber(topic, name, messageSelector, noLocal)? i.e. if I have 2 subscriptions with the same name, it starts acting as a queue and the messages are sent in a round-robin manner. I want to avoid this.

[Arnaud Cogoluègnes]

>
> To implement durable subscribers in the RabbitMQ JMS Client, one has to declare a queue as durable and use routing keys to receive messages from the producer. Everything works fine, and this is how I declare the subscription -
>
> messageConsumer = session.createDurableSubscriber(topic, "DurableJMSSubscriber1", "", false);
>
> Now, the queues are separately created for each subscriber based on the name I assign.
>

The JMS client takes care of creating a queue for each subscriber and
binding it to the jms.durable.topic exchange using the name of the JMS
topic as the queue (this is all done automatically).

> However, in plain JMS, you also had to assign a client ID on the connection to distinguish different durable subscribers and it would throw an error in case of a duplicate ID.
>
> 1) In RabbitMQ JMS, I can still set a clientID for a connection, but it doesn't seem to do anything. Does it serve any purpose?

Not really here, it's just used on the client side and is not
propagated to the server. It doesn't help to enforce JMS durable
subscriber guarantees here.

> 2) Is there any function or configuration that checks for the same subscription name in session.createDurableSubscriber(topic, name, messageSelector, noLocal)? i.e. if I have 2 subscriptions with the same name, it starts acting as a queue and the messages are sent in a round-robin manner. I want to avoid this.

There is if everything happens from the same JMS connection (durable
subscriptions are tracked on a per connection basis). The scenario you
suggest can occur for 2 durable subscribers with the same name and
from 2 different JMS connections. You'd better off picking different
subscribers names because each ends up mapped to an AMQP queue. The
JMS client can provide some protection, but only within the scope of
the same connection.