1

I am going to be using Payara BTW....

Suppose I have:

  1. A JMS Topic

  2. An MDB configured as a durable topic subscriber

  3. Multiple instances of the MDB are deployed across the cluster and they are all using the same client ID value to make the durable subscription.

If this is the scenario, and given the way client ID values and durable subscriptions work, is it correct to say that only 1 of the MDB instances across the cluster will succeed in connecting and the others will fail?

Thanks!

Suppose you have a MDB deployed to a cluster, so there are multiple MDB instances across the cluster attempting to listen.

Michael Remijan
  • 687
  • 7
  • 22

1 Answers1

0

As of the JMS 2.0 API [1], you can share the same durable subscription across nodes in an application cluster.

The following change has been made to aid scalability:

Applications are now permitted to create multiple consumers on the same durable or non-durable topic subscription. In previous versions of JMS only a single consumer was permitted.

You can use the JMS 2.0+ API to create a shared durable consumer using the JMSContext.createSharedDurableConsumer() methods [2]

[1] https://java.net/projects/jms-spec/pages/JMS20FinalRelease#What_s_new_in_JMS_2.0? (the ? is part of the link - go figure)

[2] https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html#createSharedDurableConsumer-javax.jms.Topic-java.lang.String-

Michael Peacock
  • 2,011
  • 1
  • 11
  • 14
  • I'm actually trying to ensure only 1 will handle the message – Michael Remijan Jul 05 '16 at 00:07
  • In your scenario, it appears that you want your topic to act as a queue. The semantics for topics are such that all configured clients can subscribe and receive messages. In a queue, however, only one consumer will. https://docs.oracle.com/cd/E24902_01/doc.91/e24429/appx_topic_or_queue.htm#EOITW196 Is there any way you can set up a queue rather than a JMS topic? – Michael Peacock Jul 06 '16 at 13:31
  • A queue wouldn't work. I need multiple clients (A,B,C) to be able to consume the same message, but if there are multiple instances of a client (A1,A2,..,N) the messages should be consumed by only one of the instances. Queues I don't think would get me there. – Michael Remijan Jul 06 '16 at 16:53
  • @MichaelRemijan : I am into the similar situation now. How did you resolve your issue? I am running my subscriber in a clustered environment (A1, A2, A3) so all these subscriber instances start picking and processing the same TOPIC. How can i restrict it in a way if A1 picks some TOPIC then other twos (A2 and A3) shouldn't pick that one. – user3007165 Jul 03 '18 at 06:12
  • I never did implement a working solution for this. After much research, the solution is to configure your broker to forward messages onto other queues. So it would work kind of like this. Custer instances A1, A2, A3, are configured to listen to queue A. Custer instances B1, B2, B3, are configured to listen to Queue B. The message producer publishes a message onto Queue X. The broker is then configured to automatically forward messages from Queue X onto both Queue A and Queue B. This achieves the goal of the producer knowing about only one queue but multiple clusters get the message – Michael Remijan Jul 03 '18 at 14:59
  • If you pursue this and get a working example please let me know. I'd like to collaborate on a blog article. – Michael Remijan Jul 03 '18 at 15:00
  • MichaelRemijan, did you try the solution given by @MichaelPeacock to configure “shared durable consumer”? I am in same situation and old like to know if you had any challenges with that. – Gopi Nov 19 '19 at 13:55