Hi,
Even though it has been about a month since the last comment in this thread, I will add my question here since I think it is a direct continuation of this discussion. I want to follow up on Jeroen’s comment. I am facing the same problem of figuring out how pass instance-specific props to my persistent actor using cluster sharding. I understand the solution of initializing it with a command, and this would work in the situation of the given AuctionActor example where secondary properties are set, but how about the situation where you would like to set an instance-specific persistence id? In my case, I am trying to implement a domain actor representing an entity with its own unique identifier. I would like to use the same identifier for persistence (or a hybrid including the entity id) so that I can easily trace events related to this actor in the event logs and conveniently reclaim the actor through the entity id which I would always know. While using persistence without cluster sharding, passing an identifier via props and assigning it to persistence id worked fine. However, with cluster sharding, I admit I am confused on how to implement this functionality. Using an initialize command won’t work, since I cannot change the persistence id after the fact. I have looked at the akka-cluster-sharding template with its post example, but this hasn’t cleared my confusion. a) It looks like separate ids are used for the post entity vs persistence, but I assume that this is just a preference of the template and not a requirement. Since the id extractor recovers the post id, how does the cluster know which persistent actor to use? Looking at the code, the persistence id is totally different and I cannot see how the persistence id would be retrieved from the post id, which is a uuid in the test spec. b) I also cannot see how the persistence id generated by the combination of self.path.parent.name and self.path.name can be unique for each post actor. Wouldn’t the parent be the same for most if not all requests? On the other hand, if there is a single post actor serving all incoming requests, I admit I cannot understand the become logic within the actor since it looks like it would accept only one AddPost command. How does it handle concurrent add post requests? c) Whichever way sharding is managing this internally, I cannot see how I could reclaim a post actor outside of sharding. For example, if I would want to unit test the post actor and I would want to check that it recovers its state probably. Thus I would create an instance, then delete it, but how can I then reclaim the same actor to test recovery? Most probably, I am missing something fundamental regarding how persistent actors are supposed to be used with sharding, and the template hasn’t helped clear my confusion. Any help/guidance would be greatly appreciated. Thanks, Sinan On Tuesday, August 19, 2014 12:01:04 AM UTC+3, Jeroen Gordijn wrote: > > Hi, > > I guess that a downside of 3 is that it makes it less suitable to use in > ClusterSharding (in ClusterSharding you cannot pass instance specific props > to an actor). > > So my preference (especially with domain actors) is to create the actor > and initialize it with a command. All domain aggregates should react to > commands, so initializing with an event makes the design more consistent > IMHO. > > Cheers, > Jeroen > > -- >>>>>>>>>> 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.
