concurrently consuming messages from a topic

[tbriot]

Hi all,

I'm browsing the internet for a while and can't find a solution.

I have a cluster of two clients trying to subscribe to the same topic, using the same Connection Client ID and same Durable subscription name (load balanced fashion).

I keep getting the folllowing error :

com.wm.app.b2b.server.jms.ResourceUnavailableException: javax.jms.IllegalStateException: Cannot create a subscriber on the durable subscription since it already has subscriber(s)

Is there any way to concurrently consume messages from a topic ?

Thanks.

Regards,

Thomas

[jbertram]

Two different consumers cannot be connected to the same durable subscription concurrently.  That violates the JMS specification.  However, you can create multiple durable subscriptions with different identifiers and both subscriptions will receive the message.

You could also just use non-durable subscriptions.

[tbriot]

Hi Justin,

Thanks for your response.

- I can't use multiple durable subscriptions with different ids otherwise each of my clients will receive the message. I only want the message to be processed by one of the client.

- In my clients' vendor documentation, here is what i found :

"The Java Message Service, Version 1.1 specifies that each subscriber to the same topic receives each message. The Java Message Service, Version 1.1 does not provide semantics regarding how to concurrently consume messages published to a topic in a load-balanced fashion.

Some JMS providers work around this limitation by offering a proprietary extension to the JMS API. Review your JMS provider’s documentation to determine how to concurrently consume messages from a topic."

Does it mean that HornetQ doesn't offer that kind of extension ? (i can see that the webMethods JMS provider has this feature for instance)

Thanks.

Regards,

Thomas

[jbertram]

I'm not really clear on your use-case here.  But you say,

I only want the message to be processed by one of the client.

If that is true then why not just a queue rather than a topic?

I don't understand what it means to, "concurrently consume messages published to a topic in a load-balanced fashion."  For multiple consumers to consume messages "concurrently" would seem to mean that they consume them in parallel (i.e. simultaenously).  To do so "in a load-balanced fashio" is what I don't understand.  Does that mean that only one of the consumers actually gets the message and then the next message goes to the other consumer?  If so, it again appears like you want a queue rather than a topic.

[tbriot]

"Does that mean that only one of the consumers actually gets the message and then the next message goes to the other consumer?"

» exactly.

- You're right, a JMS queue would solve the problem. But we would lose the topic advantage of being able to have a new application subscribe to the topic and get the messages.

That's why we would like to stick to JMS Topics.

[jbertram]

You're right, a JMS queue would solve the problem. But we would lose the topic advantage of being able to have a new application subscribe to the topic and get the messages.

That's why we would like to stick to JMS Topics.

You could solve this problem by creating a new queue for the new application and a matching non-exclusive divert to copy messages as necessary.

[tbriot]

Looks like those divert objects could be helpful.

We're going to switch to a JMS queue.

Thank you very much Justin for your help.

Regards,

Thomas