Thanks, Patrik. The server-side approach is a neat alternative. Cheers, Andrew
On Thursday, 20 April 2017 12:50:40 UTC+1, Patrik Nordwall wrote: > > That is a simple and good solution. If the entity ids are known you can do > the heartbeating from an actor running on each node, or from a Cluster > Singleton, instead of from the clients. > > I know something similar is used in Lagom for keeping the read side > processors alive. > > /Patrik > ons 19 apr. 2017 kl. 14:57 skrev Andrew Easter <andrew...@gmail.com > <javascript:>>: > >> Hi group, >> >> I was wondering if anyone has any experiences/patterns to share with >> regard to ensuring the perpetual existence of sharded actors? >> >> To explain, what I mean... >> >> I'm prototyping some software that pushes data to connected clients over >> web sockets (currently using a third party service, Pusher). I have the >> concept of an actor that pushes data to one or many specific clients via >> Pusher, and, in turn, there can be many such actors, each with their own >> set of associated clients. These actors are sharded - each actor has its >> own specific configuration that determines the data it sends to its >> connected clients via Pusher, and thus I only want one unique instance of >> each specific actor within the akka cluster (wouldn't make sense to have >> multiple instances all duplicating data being sent to their associated >> clients). >> >> As the clients of an actor are essentially running forever, it makes >> sense for the actor to have perpetual existence - i.e. it always needs to >> be alive and sending data to its associated clients. At the moment, I've >> solved this by having each client send a heartbeat at a scheduled interval. >> In the event the client's associated actor has terminated (for whatever >> reason), the heartbeat essentially serves the purpose of waking it up again >> (recovering it) somewhere in the cluster. This will then ensure the actor >> starts delivering data to all its clients again. >> >> The solution I have in place does work, but I'm wondering whether there's >> a more 'elegant' solution that means the server side system ensures that >> all necessary actors remain running, even in the event of crashing, >> restarting nodes etc. Of course, maybe the solution in place is good enough >> as it's actually pretty simple. I can imagine a server side solution might >> be more involved and require a lot of complex engineering to get right. >> Anyhow, thought I'd ask in case there was some established patterns that >> people were already using for this type of thing. >> >> I imagine another example of where you might want such behaviour is if >> you were building a system like Pingdom - i.e. you create an actor per >> responsiveness test and know that you always need that actor to be awake, >> triggering the configured endpoint at configured intervals. In that case, >> you couldn't rely on some client sending a heartbeart to wake the actor up. >> >> Any thoughts on this would be more than well received :-) >> >> Cheers, >> Andrew >> >> >> -- >> >>>>>>>>>> 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+...@googlegroups.com <javascript:>. >> To post to this group, send email to akka...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > -- >>>>>>>>>> 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.
