Hello Muthu, that is certainly an interesting use case you have. Would love to hear about the final solution you will end up with.
I think that you should not store ActorRefs in the DB because they can get stale if the corresponding actor will be stopped and started again. Instead you can store only the name or full path of the actor and do ActorSelection to get ActorRef. On Sun, Jul 27, 2014 at 9:33 AM, Muthukumaran Kothandaraman < [email protected]> wrote: > I have a domain problem where the graph of actors (actors as nodes of > graph and links represent communication channels between actors) is not > dictated by the natural supervisory hierarchy but by external configuration > of connectivity between actors - which is stored in Neo4j. Most of the > actors representing nodes of the graph are long-living in nature. Other > characteristics include > > - Short-lived actors never form part of the "actor graph". End users (not > necessarily humans always) can control the lifecycle of nodes and edges of > graph. - > > - Lifecycle of actors (nodes of graph) is aligned with the lifecycle of > corresponding nodes in graph-db. This rule also applies to edges. So when > one of actors receive a specific message, it has to query the graph > database and > route the message to other actors. Receiving actor may or may not > execute any other business-logic before forwarding message to other actors. > > So, I am thinking of following option : > > Have some neutral Actor-identifier stored in the Neo4j with ActorRef as as > one of node attribute and use the graph query mechanisms for various query > types (immediate neighbors, immediate neighbors filtered based on edge > properties etc etc) and determine the target actors to which the messages > could be forwarded. I would have to think about the robustness aspects of > actor-deaths and probably caching query-results from Neo4j within each > actor for specific type of query (so that we do not hit Neo4j for each and > every message) etc. But I could think of such cases once the basic approach > is decided. > > Above approach is effectively trying to treat Neo4j as a logical > graph-overlay for actors. > > I wanted to get opinions from experiences of others. > > PS : I would still use supervisor actors primarily for managing the > activities such as child-restart upon crash and supervisor actors need not > necessarily form part of actor-graph. > > Thanks in advance > > Muthu > > -- > >>>>>>>>>> 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. > -- Martynas Mickevičius Typesafe <http://typesafe.com/> – Reactive <http://www.reactivemanifesto.org/> Apps on the JVM -- >>>>>>>>>> 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.
