Thanks Jeroen, that helped me finally realize what I was misunderstanding. Somehow it got stuck in my mind that the extracted id corresponded to the persistence id, hence my confusion. Now, when I went back to the docs and read it once more, the curtain lifted and I finally saw the comment in the sample code which says that ‘self.path.name is the entry identifier’ . Hence the extracted id is used as the actor name, and persistence id is a separate concern. I think akka has really good documentation, but apparently it’s still not enough when you go brain dead like I did :)
On Tuesday, September 23, 2014 10:59:07 PM UTC+3, Jeroen Gordijn wrote: > > Hi Sinan, > > The name of the actor that is created in the cluster is stable and can be > used as persistenceId, In the Example the name of parent concatenated with > the entityId is used. You could as wel create the id yourself like: > > 1. def persistenceId = "orders-" + self.path.name > > > This way you know the persistenceId and you re-create the actor in the > same way as you had created it in the first place. > > HTH > Cheers, > Jeroen > > > Op dinsdag 23 september 2014 09:26:52 UTC+2 schreef sinel: >> >> 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.
