This issue covers the implementation of
MQ-178 in the JMSRA client (both direct mode and TCP mode). For the avoidance of doubt this issue covers only the JMS API. It does NOT cover message-driven beans.
The APi required is exactly as defined for
MQ-178. However when implementing this feature there is one additional issue to consider. This is how the new JMS 2.0 API for topic subscriptions interacts with JMSRA's existing "shared subscriptions in a cluster" feature.
The current "shared subscriptions in a cluster" feature (for applications using the JMS API)is defined in
Attempts by multiple connections to use the same client id do not result in an exception, provided that the connections are from different instances in the cluster.
Two or more subscriptions on the same topic with the same client id and (if the subscription is durable) the same durable subscription name are considered "shared"; that is, they are treated as a single subscription, with each message being sent to only one of the participating subscriptions.
The sharing of subscriptions relies on client id being set, not only for durable subscriptions (which always require client id) but for non-durable subscriptions (which do not normally require client id). If the subscription is being created by the resource adapter for use by a message-driven bean (MDB), and client id is not set, then the resource adapter will set the client id to the name of the MDB. However if the subscription is being created programmatically using the JMS API, and client id is not set, then an exception will be thrown.
Now that the JMS 2.0 has decided to keep the existing behaviour of createDurableSubscriber (and createSubscriber), there is no overlap between the two features.
- createDurableSubscriber and createSubscriber will continue to behave as they do now, with the existing non-spec-complaint "shared subscriptions in a cluster" behaviour (which allows duplicate clientId and requires clientID to be set even for non-durable subscriptions).
- createSharedConsumer and createSharedDurableConsumer will exhibit the new JMS 2.0 behaviour (and so not support old-style JMSRA shared subscriptions)