Hi Henrik, I think this sounds like a good fit for persistance together with sharding.
If you use sharding you will not "know" where the sharded actors are, but address them with their id. Your controllers will however need to get their hands on the ShardRegion to send messages to the sharded actors. The shard region will be a local actor and does not move around so it is pretty much safe to look it up during the bootstrap of your controller and then keep that ActorRef for all your interaction. One reason why it could be an idea to think about moving away from spring to akka-http in the future is that spring will block one thread until the request is done, so you will have to block it to wait for the reply from your sharded actor, and keeping that thread from taking other requests. While akka-http is asynchronous all the way and will allow the "controller" to return the thread pool and then react on the reply from the sharded actor. -- Johan Andrén Typesafe - Reactive apps on the JVM Twitter: @apnylle On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson wrote: > > Hi, > > We have finally gotten around to try to migrate a fairly standard Spring > REST application to Akka. It will be using the Java API (scala knowledge is > moderate at best) and we could need some advice around the approach. > > The initial thought was to keep using the Spring based REST API i.e. keep > all controllers and client facing API/Json serialization and use Akka > persistance and sharding for our entities. Why we think this would be good > is that we have quite well defined entities where the identity is explicit > and guaranteed to be unique. We are also fond of the eventsourcing model. > The idea is also that querying the entity for its current state would > simple be a matter of rendering its current state and thus saving a trip to > the database and result in better performance. We are talking perhaps > single digit millions of these entities. > > Where we find that we lack explicit understanding is how we get hold of > the actors from the controllers (or whatever service actually performs > actor interactions). Looking up persistent actors (without sharding for > simplicity) using Patterns.ask seems to work but we are unclear as to > whether or not that is the way to do it. Should we do that whenever we need > to get hold of an entity and is there any (significant) overhead? We would > prefer not to cache the actors and it seems counterintuitive as well since > actors target locations can change. Also maintaining invalidations seems a > hassle. > > Any help and advice would be greatly appreciated. Caveats and gotchas etc > also very welcome. > > Thanks, > Henrik > > -- >>>>>>>>>> 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.
