Hi Patrik, The main problem with Distributed Pub/Sub is that in order to kick-off the process I must load all of my persistent actors on startup to be able to subscribe them :). There is also a passivation on the actors. If they are not updated for a long time I want to shut them down but don't cancel their subscriptions. Those are the reasons why I decided to route message to persistentId instead of ActorRef.
And yes the reliable delivery of messages will be hard as well. I'm using op-rabbit for message consumption. If you have advises how to approach this problem I'll be very grateful :) Thanks a lot for your time! On Wednesday, 11 January 2017 15:21:32 UTC+2, Patrik Nordwall wrote: > > You can perhaps use Distributed Pub/Sub > <http://doc.akka.io/docs/akka/2.4/java/distributed-pub-sub.html> for > this. The difficult part is to reliably deliver the messages to all > subscribers. Messages may be lost or subscribers may not be running when > you consume the message from Rabbit. That is not handled by Distributed > Pub/Sub and if it's important it's something you would have to think about > if you roll your own solution also. > > Regards, > Patrik > > On Wed, Jan 11, 2017 at 11:23 AM, Ivan Nakov <[email protected] > <javascript:>> wrote: > >> Hi guys, >> >> I have a service that consumes messages through RabbitMq channel and >> should forward them to PersistentActors behind ClusterShard. >> The tricky part is that each persistent actor must subscribe himself for >> a specific messages and receive all messages from these types. For example: >> message1 - should be delivered -> persistenceId1, persistenceId2, >> persistenceId3 >> message2 - should be delivered -> persistenceId1, persistenceId4 >> >> I'm thinking for the following solution: >> >> 1. Implement a MessageCоordinator as cluster singleton. The >> Coordinator is going to contain all subscription and persist them. >> 2. Every persistent actor is going to register himself after >> initialization in the Coordinator. He's going subscribe messages with his >> persistentId(insted of ActorRef). >> 3. Each node is going to start its own "MessageRouter". The router is >> going to fetch recipients list from the Coordinator and subscribe for >> update of the list with it's ActorRef. If there is change in list the >> coordinator is going to notify all routers. >> >> Is my approach reasonable? Is there a better solution to this problem? >> >> >> Cheers, >> Ivan Nakov >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Patrik Nordwall > Akka Tech Lead > Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM > Twitter: @patriknw > > -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
