A shared non-durable subscription is used by a client which enables to share the work of receiving messages from a durable subscription amongst multiple consumers. A shared durable subscription can, therefore, have more than one consumer. Each message from the subscription will be delivered to only one of the consumers on that subscription.
A shared durable subscription is created, and a consumer created on that subscription, as specified by the JMS specification. A shared durable subscription is identified by a name specified by the client and by the client identifier if set. If the client identifier is not set for a JMS connection, by default, Fiorano assigns a provider-specific identifier such as a string starting with "JMS_FIORANO_CLIENT_ID_" followed by a numerical value that is unique for each such connection.
In case of shared durable subscriptions, it is not essential to set client identifier for the JMS connection. So, if client applications are coded in such a way and as Fiorano provider assigns a default identifier which changes randomly for each instance of connection creation, there will be a NEW durable subscription created each time an application goes offline and comes up which is erroneous.
In order to resolve this issue, in order to identify a shared durable subscription Fiorano provider assigns a secondary identifier (to a JMS connection for which client identifier is unset). This name can be unique for all shared durable subscriptions across the JMS provider or unique for all subscriptions under a topic. This behavior can be changed by the parameter which can be configured in the following way -
Online Configuration
- Open Fiorano eStudio
- Login through FMQ-JMX and traverse to Fiorano > mq > pubsub> PubSubManager > TopicSubSystem > config.
- Modify 'UseTopicIDBaseForSharedSubs' parameter
- Save configuration and restart server
Offline Configuration
If this 'boolean' parameter is set to true (default value - false), the secondary client identifier will have the topic's name within it. In such a case, rather than using the normal way to unsubscribe a durable subscription from client application using only the subscription name, it must be done in the following way -
Java