Client ID and Enable Clone support on a TCF
The enable clone support setting is specifically for durable subscription based publish/subscribe messaging on the WebSphere products. The Client ID is used to aid clone support of publish/subscribe messaging. Enable clone support permits listener ports defined with the same TCF to share a durable subscription, as long as they have a cloned application deployed against them.
Component: TCF Applies to specific messaging topologies: Yes Requires specific usage of JMS in application: No Location of settings: Resources | WebSphere MQ JMS Provider | WebSphere MQ Topic Connection Factories | Your_TCF | Enable Clone Support When using publish/subscribe there are two ways in which client subscriptions can be handled, durable and non-durable. If a client subscribes to a topic using a non-durable subscription and then is terminated or loses network connectivity, it will not receive any future publications until it is started again. Any publications occurring whilst the client is unavailable will be lost.
Durable subscriptions mean that a clients subscription lives past the termination or loss of communication of that client. Whilst the client is unavailable, the broker keeps a copy of any published messages requested in the clients durable subscription. When the client starts back up again the messages are then received by the client.
As a durable subscription lives past the termination of the application client, the only way to remove the durable subscription is to deregister it from the broker. If you are using a durable subscription on an MDB then the durable subscription is only removed when the application is removed from WAS, and only then when that appserver is restarted so that it can tell the broker of the subscription change.
There are different rules for how to create a durable and non-durable subscription, because of the persistence needed for a durable subscription.
A non-durable subscription works in a similar way to listening on a queue for a message to arrive. In the case of a message driven bean, WAS uses a listener port to create the necessary JMS objects to point to the required topic. If any of those objects are closed or the link with the message broker is lost then the subscription is also lost. From the broker's perspective it recognizes a distinct subscription by the TopicSubscriber that has been used. Each communication channel opened to the broker is a new subscription from a new client.
A durable subscription cannot be identified by the connection to the message broker as once it is closed or lost, so would be the subscription. Instead, the broker recognizes the subscription based on the ID of the durable subscription. This ID is based on a set of parameters which form a unique reference. If the client should stop, then when it is started again it will be recognizable to the broker by the fact that it has the same ID.
If a client, in particular an MDB with a durable subscription, wishes to subscribe, it needs to have a unique durable subscription ID. This ID is created using the:
Problems start to occur if the application is clustered. If there is only one installation of the application running, then this MDB's subscription remains unique for this broker. But if another copy of the application is started up pointing at the same TCF then the subscription is no longer unique on the broker. The second MDB will not function as expected.
For this reason, when clustering an application you will need to carefully choose how many TCFs serve your MDBs and the settings on those TCFs.
Two different types of behavior with a durable subscription and MDBs are possible:
- The application is installed in a cluster. All the MDB listener ports are configured to point at one TCF, which is defined at the lowest scope that allows all your appservers to view it. This will be either cell or node depending on your topology. This TCF has Enable clone support checked and a Client ID specified (both are fields on a TCF for Embedded JMS and MQ JMS providers).
When all the servers in your cluster are started, the MDBs and their listener ports will start successfully. When a message is published only one of the MDBs will get the message, so only one of the cluster members will receive the information within the message. This is because the broker only sees one subscription as the client ID on the TCF and the name of the MDB are the same for each appserver. It is at this point that the Enable clone support setting needs to be used. The JMS specification states that there can only be a single subscriber for a particular durable subscription at any one time. Enabling clone support allows all the MDBs to successfully start even though they all have the same client ID for the durable subscription. Without this setting turned on, only one of the MDBs will work properly. With enable clone support turned on, the JMS provider will then pass a publication to any one of the MDBs.
Whichever of the listener port sessions is available first will receive the message. This is like one grouped line of customers waiting to be served by a number of cashiers, where the line of customers is the topic publication messages and the cashiers are the listener ports. There are four cashiers working, each dealing with a customer, when one of them finishes their work the next customer in the line goes to that cashier. If a line never forms then the cashiers will not be busy and so the next customer to arrive could go to any of them. This method of distributing the workload means there is no algorithm that can be applied to understand which cluster member will get any given message.
This behavior occurs because the broker sees one subscription. When a message is published that matches this subscription, the MQ JMS classes take the message and then pass it to whichever of the listener ports is available first to process the message. This behavior occurs because Enable clone support has been specified, it is telling the MQ JMS provider to allow multiple MDBs (one in each clone), but only use one at a time.
Note that this scenario means that all MDBs use the same communication mechanism to reach the message broker.
- The application is installed in a cluster. Each MDB listener port that is defined has its own TCF, which is defined at the server scope. Each TCF does not need clone support checked, but does need a Client ID specified. The client ID field must be a unique value amongst all TCFs defined to use the same broker.
When all the servers in your cluster are started, the MDBs and their listener ports will start successfully. When a message is published, all of the MDBs will get the message, so all of the cluster members will receive a copy of the message. This behavior occurs because the broker sees multiple subscriptions, one for each appserver.
It would be possible to configure a topology that is somewhere in between these two behaviors (more than one TCF but not one per appserver) but the functionality provided would be complicated to work out.
If you are using durable subscriptions in a clustered environment then it is essential that the correct behavior is created through the configuration of your JMS components.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.