To close the loop on this, here's what I ended up doing. Originally, a node would either start a Master actor system or a Worker actor system, depending on startup flags. (Again, Master would not communicate with Worker or vice versa through messages; each node was self-contained.)
After changing it, all nodes start (join) the same Cluster actor system. I created a "Switchboard" Actor that can behave in either Master mode or Worker mode via context.become. I used ClusterSingleton to start an actor that does nothing other than send a message to SwitchboardActor to change its mode from Master to Worker. The Singleton actor does not receive any messages itself; it only serves to send that message to Switchboard upon startup. Seems to work fine, and now we don't need to use startup flags to specify which node is Master or Worker. The cluster figures itself out. Not sure if this is a classic pattern, but it seemed pretty straightforward, and didn't require any changes to actual workings of our Master/Worker systems. Curt On Friday, March 18, 2016 at 12:56:43 AM UTC-7, Curt Siffert wrote: > > Hi, I'm supporting a pre-existing Akka project that is currently set up to > run 1 Master instance and N Worker instances. > > It does not use routing/remoting. We start them in 'Master' or 'Worker' > modes via startup flags - each instance has its own actor system, and the > only information they communicate to each other is through Redis Pubsub. > Each of them does accept API requests so they are all behind a load > balancer. > > The Master actor system and the Worker actor system are slightly > different, in that Master polls some information and publishes to Redis, > while Worker subscribes to Redis so they all have the same information to > serve to the API requests. > > Now we have a desire to start up N instances without using the startup > flags, and have the instances just figure out for themselves which is > Master - and if it goes down, another would be master, etc. We don't want > more than one Master, since only one should poll the external information. > We don't need to send application messages across nodes since we'd keep > Redis. > > Looking at the Akka Cluster tutorials, I'm seeing a couple of options on > how to do this: > > 1) Just use leader election, and listen for LeaderChanged messages to make > Leader always be Master (stopping the Worker actor system and starting the > Master actor system if necessary). But this seems against the spirit of > keeping leader election decoupled from application functionality. Plus, in > experimenting, I'm seeing nodes switch Leader more often than I'd like > Master to switch (like if I take node #1 down and then bring it back up - > node #1 seems to end up Leader again even if node #2 was Leader for that > intervening time). > > 2) Use ClusterSingleton - but if I did this, what would be the way for the > Worker nodes to realize it is not the Master Singleton and start up the > different Worker actor system? With no routing/remoting, Master would not > be sending messages to them. > > It seems like this is a bit against the spirit of using Akka Cluster which > seems to assume routing. Is there a better way? > > Thanks, > Curt > > -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
