While I don't think this is a good problem domain for akka (I have my own service for this written in finagle), using DDATA may seem like the easy way to do shit but I don't suggest that either, if you must use akka here's what you should do (you're gonna have to write your own behavior), you segregate the types of services in groups, you have a consistent hashing router with the key as the group name, you register interest of these groups, the processes who the request was routed to registers the interested actors actorRef into it's table, when a new service registers itself to that process, you create a broadcast router from those actor refs and send it all out, for replication of this data, (this isn't going to be pain free ) you get the routees from the consistent hashing router you remove yourself from the routees and generate a new one. You then forward it to the next closest actor using a replicate case class so it won't do the aformentioned behavior, on service registering to said actor.
In essence I basically described a crappy but doable version of Riak Cores pg, https://christophermeiklejohn.com/erlang/riak/crdt/2013/06/24/introducing-riak-pg-distributed-process-groups-for-erlang.html. The reason why actors are not a good way to do this is because One Message at a time == bottleneck, message passing with unreliable delivery, creating all of these objects isn't cheap. Having a clustered set of servers that that a set of actors watch for updates, and broadcast the news, is a lot more efficient and reliable. Akka is a very useful tool but it's not the best solution for everything. You could also implement something stupidly simple with just cluster PubSub. I suggest you learn you some erlang. On Friday, March 24, 2017 at 6:44:39 AM UTC-4, Unmesh Joshi wrote: > > Hi, > > We are working on implementing common services backbone using Akka. > To start with, we are implementing a service registry mechanism and > evaluating Distributed Data for implementing it. I was going through > ServiceRegistry samples at > https://github.com/akka/akka-samples/blob/master/akka-sample-distributed-data-scala/src/main/scala/sample/distributeddata/ServiceRegistry.scala > and was curious to know if there is any specific reason to maintain local > state for list of services in ServiceRegistry actor. > > In our implementation, we are directly sending Get message to Replicator > while doing service lookup. > Is there is any downside of sending Get message directly to Replicator? > > I am interested in knowing if Distributed Data for Service Locator is used > in any of the projects you know of, and to know any lessons learnt. Just > curious, is this something that is used internally by ConductR as well? > > Thanks, > Unmesh > -- >>>>>>>>>> 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.
