Re: [akka-user] Distributed reliable pub-sub with Akka

[Rich Dougherty]

Hi Matthew

Have you looked into some of the messaging products out there? I don't know too much about them, but I'm pretty sure reliable pub-sub is a fairly standard feature, ie part of the JMS API. Depends what exactly your requirements are.

Rich

On Fri, Jan 4, 2013 at 10:30 AM, Matthew Hodgson <matthew...@openmarket.com> wrote:

Hi all,

I'm looking at using Akka to provide a distributed reliable pub-sub event bus for a Java app, and have a few questions:

1. Should I give each JVM node its own EventBus, and have each actor on each node subscribe itself to each EventBus by remoting a message to some kind of node-manager actor, and then receive published messages from the publisher's eventbus over remoting?

2. Or should all messages between nodes be routed only between designated node-manager actors, and then delegated to local actors?

3. Are there any advantages of using EventBus locally for this at all, or should I manage my own mappings of publishers to subscribers?

4. Should I be using akka-cluster to keep track of what nodes are present in my cluster, and managing the lifecycle of my pubsub based on the reported lifecycle of the nodes?

5. Finally: is Akka actually the right tool for this at all?  Is there an easier solution?  I'm slightly surprised that this isn't a typical out-of-the-box example use case...

thanks in advance,

Matthew

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
 
 

[Evan Chan]

Hi Matthew,

By "reliable", I assume that what you need is guaranteed, exactly once message delivery semantics, is that right?

If I was to build it on top of Akka, I would use actors instead of EventBus, and combine it with the eventsourced library, which provides journaling and replay of messages (for at least once) as well as deduping (for exactly once).

In general, though, if the message throughput is low to medium, AMQP is a good choice as it allows "checking out" individual messages and confirmation semantics, as well as resending failed messages.

Kafka works pretty well for high volume messaging, and is persistent to boot, but you need to put in more work to make the reliable aspect work.

-Evan

On Thu, Jan 3, 2013 at 3:19 PM, Matthew Hodgson <matthew...@openmarket.com> wrote:

Hi Rich,

The various AMQP and JMS products out there seem a little heavy and enterprisey to me - hence looking at lighter weight building blocks like Akka or zeromq to provide the necessary functionality.  For instance, it seems a shame to run an erlang-based message broker like RabbitMQ when java/scala already has the necessary building blocks in the shape of Akka.

Is it the case that Akka is too low level for this sort of thing, though?  My exact requirements are pretty much classic reliable pubsub notifications.  Previously I simply sent DIY multicast packets to announce events from one app node to the rest of the cluster, but they are obviously not reliable and I didn't implement subchannel subscriptions, which is why I'm looking for an alternative.

Matthew

--
--
Evan Chan
Senior Software Engineer | 
e...@ooyala.com | (650) 996-4600
www.ooyala.com | blog | @ooyala

[Jonas Bonér]

On Fri, Jan 4, 2013 at 3:19 PM, Matthew Hodgson <matthew...@openmarket.com> wrote:

On Friday, January 4, 2013 1:30:15 AM UTC, Evan Chan wrote:

Hi Matthew,

By "reliable", I assume that what you need is guaranteed, exactly once message delivery semantics, is that right?

In this instance, I mean that notifications are delivered at least once - assuming the target is actually present in the cluster.  In other words, message acknowledgement/retransmission and some level of cluster management to ensure the target is valid.  De-duping isn't so important, as the notifications are idempotent.

 

If I was to build it on top of Akka, I would use actors instead of EventBus...

I was under the impression that EventBus is just plain java/scala, but tracks subscriptions to channels in a map and then uses that map to delegate publishes through to the right actor.  In other words, it's layered on top of actors?

 

...and combine it with the eventsourced library, which provides journaling and replay of messages (for at least once) as well as deduping (for exactly once).

Interesting - I hadn't spotted eventsourced.  And I hadn't considered the race condition that a publisher might die before it can retransmit its notification to a slow-responding subscriber, and so had been ignoring the persistence/journalling side of things.

 

In general, though, if the message throughput is low to medium, AMQP is a good choice as it allows "checking out" individual messages and confirmation semantics, as well as resending failed messages.

Kafka works pretty well for high volume messaging, and is persistent to boot, but you need to put in more work to make the reliable aspect work.

Right. So it sounds like Akka itself is too low level to provide an 'out-of-the-box' solution to this, and one would have to write some level of messaging framework on top of it like eventsourced.  Does anyone else have good solutions for doing this?  Dare I ask whether jgroups works for this sort of thing?

I wouldn't use JGroups for anything at all, ever. 

If you need node membership then use Akka Cluster. 

I think eventsourced can get you pretty far. 

 

 

Matthew

--
Jonas Bonér
Phone: +46 733 777 123
Home: http://jonasboner.com
Twitter: @jboner