This content has been marked as final. Show 3 replies
I'm running OpenMQ 4.5 (conventional cluster, two servers) and two instances of Glassfish (not clustered, different servers). I have the same application deployed on each GF instance. I have a few topic listeners that run processes which should only be executed once. It worked as I wanted on a single instance, but now the same listener class in each GF instance is called when the message arrives (exactly as you'd expect).Yes, this is the expected behaviour. If the GlassFish instances are clustered, the topic subscription will be "shared" so that each message will only be delivered once (given the same client ID and, if the subscription is durable, the same subscription name). If the GlassFish instances are not clustered you will get normal JMS behaviour: client ID must be different in the two instances, and each message will be delivered once to each subscription.
If I ran a GF cluster it'd work in this way (only one of the nodes would pick up the topic message). I've tried setting a clientID on the MessageListener, but then it fails when I try to deploy the application to the second server ("Client ID is already in use").
I'm reluctant to run a GF cluster because that's been causing other problems. Another option is to rewrite the code to use queues rather than topics, but that could involve a fair amout of effort and limits me going forward (I like the option of hooking in new processes to a topic).
Nigel, thanks for confirming what's happening. So, there's no way to configure OpenMQ to provide the same kind of "shared" subscription behaviour?
Okay, have read some more of the documentation and understand what's going on. The "shared subscription" feature is provided by the jms resources adapter when run in a clustered container - it's not provided by OpenMQ.