Hi, is there a way to list all topics to which an actor has subscribed to?
I read the documentation
in
https://github.com/akka/akka/blob/master/akka-contrib/docs/distributed-pub-sub.rst
and the javadoc but i could not find anything...
On Thursday, April 4, 2013 3:27:23 AM UTC-3, Rajiv Kurian wrote:
>
> I am trying to build the following system:
>
> 1. I have a cluster (not necessarily an Akka cluster) with say n nodes.
> 2. A publisher publishes an event (the publisher may or may not be an
> actor). This event needs to be forwarded to certain subscribers which are
> actors.
> 3. The event should be reliably routed to all subscribers at least once
> (duplicates can be resolved by the subscriber).
>
> My current thoughts are:
>
> 1. Have a subscription manager actor per node. This actor receives a
> remote message for each event.
> 2. Have a publisher actor or a few publisher actors per node. Publishers
> publish events through these publisher actors. The publisher actor -
> subscription manager pair would implement a protocol for "reliable"
> delivery of messages. Maybe using the event-sourced module would be useful
> here.
> 3. When a subscription manager actor (one per node) receives an event it
> routes it to the right local subscribers. All subscribers are actors. My
> reason for the one subscription-manager actor per node is mainly ease of
> implementation. I don't need to keep an up to date subscription list on
> remote nodes. Also it may be more efficient than sending identical messages
> to multiple remote actors. The reliability protocol will also be less
> chatty across the network since there is a single recipient. The
> subscription-manager to local actors might also need a reliability protocol
> though retransmissions won't need to travel across a network. The Akka
> documentation also implies that losing local message is extremely unlikely,
> so I might even give up on local reliability.
>
> On a tangent does any one know if sending the same message to multiple
> remote actors in a loop is optimized?
> ie remoteActors foreach { _ ! SomeMsg }. Will this serialize this message
> only once per remote node and have some manager send it to all local actors?
>
>
> I am wondering whether the following Akka features would be useful:
>
> 1. Event-Bus for routing messages to subscribers locally. I could just
> maintain the topic -> subscribers mapping in a multi-map and send an actor
> message to each subscriber. Is there anything to be gained from using the
> event-bus here?
> 2. Akka-cluster for the publisher to send messages to each subscription
> manager actor (again only one per node). This pretty much entails knowing
> all nodes in the cluster and attempting to send them a remote message/local
> message. I won't have dynamically joining nodes so I could just send
> messages to a static list of nodes. Ignoring the reliability layer for now.
>
> I still don't know how I would detect a subscription-manager actor on a
> remote node going down or becoming temporarily unavailable? I also want to
> make sure all subscription-manager actors are up before starting the rest
> of the system. These might be easy with Akka cluster support too.
>
> Has any one built such a system using Akka? Your comments will be
> invaluable to me and could save me a lot of effort. I know there exist
> other queueing systems with persistence but I would like to use Akka to
> accomplish this since the rest of my system is also built on Akka.
>
> Thanks,
> Rajiv
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> 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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
