Should we ever call setClientId() on the connection factory?

5
votes

This is in the context of creating a durable subscription.
There is a setClientId() in DefaultMessageListenerContainer and another one in SingleConnectionFactory.

My understanding is :

  • Durable subscription is for a consumer/subscriber.
  • Different consumers should be capable of using different client ids.
  • Different consumers should be able to share a connection.
  • There is one (ListenerContainer,Listener) pair per consumer.

So, it makes sense to setClientId() at the ListenerContainer.

But, Why would there be a setClientId() at the connection factory level ?

Even though the SingleConnectionFactory has only a single connection, that connection could be shared by multiple consumers, across multiple sessions. Right ? Needless to say that it is more dangerous for a CachingConnectionFactory (which inherits this method from SingleConnectionFactory).

Extended version: Can we say one should NOT use the setClientId() on a Single/CachingConnectionFactory ? This is made even more imperative by the following statement in DefaultMessageListenerContainer's setClientId():

Furthermore, a client ID can only be assigned if the original ConnectionFactory hasn't already assigned one

So, if someone accidentally setClientId on the CachingConnectionFactory, future sets of the client id on the DefaultMessageListenerContainer would be no-ops !

1
javaspringjakarta-eejmsspring-jms

1 Answers

4
votes

But, Why would there be a setClientId() at the connection factory level ?

setClientId() on the connection factory is used to administratively set the client id, to prevent consumer applications from setting it manually; in fact, according to JMS spec, if client id is set by the client when it was already set by the factory, an exception is thrown.

Can we say one should NOT use the setClientId() on a Single/CachingConnectionFactory?

If you need to create durable subscriptions for different subscribers, each with its own client id, use subscriber.setClientId(), because if you use connectionFactory.setClientId() and attempt to create multiple connections from the same factory with client id already set, the factory will throw an exception complaining that "connection clientId is already connected."

Personally, I like having flexibility and complete control in my code, so I use subscriber.setClientId()