Does Hazelcast support “shared subscriptions”

[Bert]

In JMS 2.0, it's possible to have a shared subscription, where multiple instances of the same service can share a subscription. Only one instance of that service will receive the message.

Is that scenario also possible with Hazelcast?

[Enes Akar]

No, hazelcast topic implementation does not support this.

On Sat, Oct 15, 2016 at 9:01 PM Bert <be...@famroos.nu> wrote:

In JMS 2.0, it's possible to have a shared subscription, where multiple instances of the same service can share a subscription. Only one instance of that service will receive the message.

Is that scenario also possible with Hazelcast?

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/654a93d8-0940-4dea-97a3-a52cb2ea5b79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Pilone]

I've been doing some work on HazelcastMQ in a "channels" branch that implements the channel and router pattern. You might be able to accomplish what you want by using a router pattern that pulls the message from a queue and routes it to consumers either directly or using additional queues. You would need to handle the case of consumers working at different speeds but a simple round-robin router might be all you need.

-mike

On Oct 15, 2016, at 2:01 PM, Bert <be...@famroos.nu> wrote:

In JMS 2.0, it's possible to have a shared subscription, where multiple instances of the same service can share a subscription. Only one instance of that service will receive the message.

Is that scenario also possible with Hazelcast?

[Nick Pratt]

You could get similar behavior with an IQueue - this allows for multiple "subscribers" to round-robin the pending messages.

On Sat, Oct 15, 2016 at 2:01 PM, Bert <be...@famroos.nu> wrote:

In JMS 2.0, it's possible to have a shared subscription, where multiple instances of the same service can share a subscription. Only one instance of that service will receive the message.

Is that scenario also possible with Hazelcast?

--

You received this message because you are subscribed to the Google Groups "Hazelcast" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

[Bert]

Thanks (Enes and Mike as well)

Do you have pointers to documentation or examples on how to set this up?

On Tuesday, October 18, 2016 at 5:37:31 PM UTC+2, Nick Pratt wrote:

You could get similar behavior with an IQueue - this allows for multiple "subscribers" to round-robin the pending messages.

On Sat, Oct 15, 2016 at 2:01 PM, Bert <be...@famroos.nu> wrote:

In JMS 2.0, it's possible to have a shared subscription, where multiple instances of the same service can share a subscription. Only one instance of that service will receive the message.

Is that scenario also possible with Hazelcast?

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.

[Michael Pilone]

Bert,

Here's an article that gives an overview of how the process worked in HornetQ before JMS 2.0. That's basically what you want to replicate (downsides and all). http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/

If you need some shared and some not shared consumers, then you want an ITopic where one of the consumers takes items and puts them on an IQueue for the shared consumers to read from. This is what the article refers to as the "divert" consumer. You'll need to write this yourself in Hazelcast but it is just a couple of lines of code to receive a topic message and offer it to a queue. If you only need shared consumers, then you can just use the queue directly and skip the topic.

As for the specifics of implementing it in Hazelcast, take a look at the getQueue and getTopic methods of HazelcastInstance. Outside of that it is normal topic/queue interaction with either listeners that get notified of messages (topic consumers) or threads that poll (queue consumers).

-mike

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/65688399-147c-47a6-ad22-f11a08776c3b%40googlegroups.com.

[Bert]

Hi Mike,

When I understand it correctly, then HornetQ takes care of the routing through a divert while for Hazelcast, that would be done in custom code (the router).

Doesn't that imply that the router becomes a single point of failure? There can only be one of them, because otherwise both of them would route messages from the topic to the queue, causing duplicates.

Or am I missing something?

Regards,

Bert

[Mike Pilone]

Bert,

Right, depending on how you implement it the router could be a single point of failure.

You have a couple of options: if you don't need other topic consumers, you can just use the queue directly which will be replicated/distributed.

Another option is to have a router on each node and use a map or some other data structure to coordinate moving messages. For example, keep track of message IDs or something.

Another option is to use a queue and a router that will distribute to multiple other queues. Basically a fan-out pattern. This is how the HazelcastMQ channels implementation works. It bypasses topics and just uses queues. You can then "bind" a queue to another queue and the router will distribute the message. This allows you to have multiple routers pulling from the input queue. Kinda like AMPQ exchanges and queues.

Another option is to use a reliable topic so you won't lose messages if the router fails but you won't get automatic recovery. You'll get the missed messages once you restore the router.

-mike

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/9e5b3964-6795-4b18-887c-86d1d66e166b%40googlegroups.com.

[Bert]

Thanks for your elaborate answer!