Does the ClientID have to be unique within the same app in Artemis

Question

This is what I have: We have 2 apps, one producing and one consuming. Both are running on different JVMs. They are sending a message to a durable topic and are using the same ClientId.

I wanted to know if the following is allowed under JMS 2.0 spec and if it's okay to do in Artemis.

• On the consuming side, I have a connection factory.
• I set the clientID on the factory by the following methods when instantiating the ActiveMQConnectionFactory bean: .setClientId("clientId") and .setEnabledSharedClientId(true)
• I have then have a class A which takes in the ActiveMQConnectionFactory type in its params. In this class there's a send method in which it checks if a connection exists, if not it creates the connection via this.connectionFactory.createConnection();.
• I then have another class which takes a type of A object in it. In this class there is an BlockingQueue array. in each element, it contains a ArrayBlockingQueue. Essentially the purpose of this class is to create create different threads to consume messages from the ArrayBlockingQueue as messages are put on them. Each thread reads from it's arrayblcokingqueue it's assigned too in it's own thread.

Now my question is is that is this allowed under JMS 2.0 spec? Is it okay that a connection is being created on different thread which is being created from the ONE/SAME connectionFactory? Should each thread have it's own ClientID?

Answer 1

As noted in section 2.14 of the JMS 2 specification the javax.jms.ConnectionFactory object supports concurrent use. Therefore, it's fine for multiple threads to use the same ConnectionFactory to create instances of javax.jms.Connection.

As far as the client ID goes, this is the relevant bit from section 6.1.2 of the specification:

By definition, the client state identified by a client identifier can be ‘in use’ by only one client at a time.

...

The only use of a client identifier defined by JMS is its mandatory use in identifying an unshared durable subscription or its optional use in identifying a shared durable or non-durable subscription.

Since your consumers appear to be sharing a durable subscription on a topic then your use of the client ID is optional.

Also, it's worth noting that org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory#setEnableSharedClientID is really an internal method designed for use in the JCA resource adapter and for certain cases involving backwards compatibility.