Ah, in a way the code I sent before is for a set of Actor systems connected between them all belonging to the same cluster, I'm not sure how Akka Cluster will perform with 1000 nodes, why so many nodes? Answering your question if a node leaves the cluster under any circumstances an event is generated on all other nodes so I remove that branch of actors from each node's cache, I only call once when a node comes up to locate the supervisor actor via selection remotely because that one is always on /user/$role where $role in ["account", "order", "signal", ..., "http"] etc
Also, children actors extend an abstract template class which basically notify the other remote supervisor of its life-cycle (created, destroyed), one node going down is an special action so child by child are not remove but their whole branch, because; they belong to a tree, a hierarchy of supervisors with children. There are special supervisors that have no children, specially for round-robin supervisor, say, a supervisor that process stateless requests and each other node have a router reference to such category instead of a single reference to a supervisor so instead of sending a message to a supervisor I send a message to a round robin router. Cheers, Guido. On Tuesday, November 10, 2015 at 12:27:02 PM UTC, Kostas kougios wrote: > > Hi Guido, mine is a similar use case. One difference is that I store the > actorrefs to files on disk as I am expecting to have a lot of them and > don't want to keep them into memory. I would expect to say have 1000 > servers with 1000 actorrefs per server for 1 "index" of mine (index = > database index as I am building a database). This means it is costly to do > batch updates of the actor refs. So what I ended doing so far is to > serialize the actor path (after injecting the real server RootAddress to > it). Then I resolveOne actorRef and I keep that ref into memory for 10 > seconds and then resolveOne again. This means that my servers don't have to > communicate up/down and it works if servers crash/restarts too. The whole > trick is achived by replacing ActorRef with EndpointActorRef (a class of > mine) which does the actorPath manipulation and takes care of serializing > the actorPath instead of actorRef. > > Overall I might end up serializing actorPath for actors in the same jvm - > if the actor is inactive for a long time. This means actors might come and > go quite frequently even if the servers are up. > > What happens to your cache if a server crashes? Do the cache removes the > invalid actor refs somehow? > > Cheers > > > On 09/11/15 23:26, Guido Medina wrote: > > Hi Kostas, > > I have few micro-services and some supervisor actors which inherited from > an AbstractSupervisor template which uses local caches per microservices > with an optimistic approach, example with requirements: > > 1) There is a uniform pattern where each micro-service is an independent > category and also each category has the capability of being either a > round-robin supervisor only or a supervisor with children (sharding) > 2) Each category informs other categories by using cluster events when a > supervisor comes up and/or any/of its children. > 3) If a supervisor dies, also its children die which means that other > supervisors in other categories are informed hence the cache for that > supervisor is invalidated. > 4) Each children has an Integer ID, say, category account and account 1, > 2, ...., 10 so I don't bother giving a path to children, I know a children > of account is ../acccount/$blah blah incarnation, so what I do to inform > caches of other microservices that Account ID X = ActorRef Y > > All this would suggest that cluster sharding is what I use but no, it is > very similar but I have my own implementation constrained more to a DDD. > > I probably confused you more than what I helped you, all I wanted to say > is that caching a key with a corresponding ActorRef is not a bad idea, of > course if one of your microservices goes down you need to invalidate caches > in order to avoid actor selection calls which I would discourage you to do, > instead (but not free since I had to put lot of work on contemplating > different scenarios), do an inventory of your events and try to react on > them. > > I particularly designed the application to build the caches using cluster > events and template pattern (preStart and postStop for some type of actors > would inform other caches) > > Having also an uniform hierarchy will help like supervisor -> children so > that you can add or invalidate a whole branch (I do that too with my > mini-framework) > > Hope all these crazy ideas can help you. > > Best regards, > > Guido. > > On Friday, November 6, 2015 at 4:15:24 PM UTC, Kostas kougios wrote: >> >> Well, I refactored my code to cache actorpaths but indeed during creation >> all actorpaths are local and when they are transmitted over the wire they >> remain local => pointing to the wrong path. >> >> I've manually modified the address part of the path myself so that it >> contains the host & port of the server. But the process seems awkward , am >> I missing something? >> >> -- > >>>>>>>>>> Read the docs: <http://akka.io/docs/>http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > <http://doc.akka.io/docs/akka/current/additional/faq.html> > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: > <https://groups.google.com/group/akka-user> > https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/n8HlIIkZhCs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at http://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 [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.
