On Sat, Apr 26, 2014 at 5:18 PM, Patrik Nordwall <[email protected]>wrote:
> > > > 25 apr 2014 kl. 19:56 skrev Todd Nist <[email protected]>: > > Hi Patrik, > > First, thanks for the response and clarifications. Going with the > default sounds fine in general, but it seems to contradict the statement in > the akka persistence documentation that states: > > > "Overriding processorId is the recommended way to generate stable >> identifiers” > > Should there be some note added to the ClusterSharding documentation that > overrides the above when in a clustered environment or am I just taking the > above statement to literally? > > Yes, I think this can be clarified. Please create a ticket > https://github.com/akka/akka/issues > Ticket created: https://github.com/akka/akka/issues/15067 > > /Patrik > > > Regards, > Todd > > > > > On Friday, April 25, 2014 2:26:17 AM UTC-4, Patrik Nordwall wrote: >> >> Hi Todd, >> >> >> On Thu, Apr 24, 2014 at 11:22 PM, Todd Nist <[email protected]> wrote: >> >>> Thanks for all the hard work that has gone into Akka. I have a question >>> in regards to processorId in the context of a sharded set of processors: >>> >>> Based on the Akka persistence documentation "Overriding processorId is >>> the recommended way to generate stable identifiers”. So if I have: >>> >>> >>> 1. An EventsourcedProcessor that is representing a Customer, say >>> CustomerProcessor >>> 2. 2 nodes in my cluster >>> 3. 10 Shards >>> 4. 100 unique CustomerProcessors each representing a different >>> customer >>> >>> What should the implementation for ProcessorId be? Looking at through >>> the ClusterSharding code, I see in the ShardRegion Class, deliverMessage >>> the it calls the idExtractor and then uses that as the name of the actor to >>> lookup the shard region for. I know that the path of the actor (minus the >>> host & port information) is used as a processorId default. >>> >> Yes, that path contains the name of the shard region, e.g. >> >> /user/sharding/Post/1234 >> /user/sharding/AuthorListing/Patrik >> >>> If a processor shares multiple aggregates, shouldn't the shard id be >>> part of the processor id? >>> >> I'm not sure I understand what you mean, but if you override the >> processorId in BlogPost it should be something that is unique across all >> processors in your system. When using cluster sharding I think the default >> processorId is what you want in most cases. >> >> >>> I’m missing how the shard region is associated to the ProcessorId or is >>> it? It is my understanding that there can only be 1 instance of a >>> Processor running with a given processorId in the cluster, so I have >>> to believe this is associated in some way or is that up to the creator of >>> the CustomerProcessor to make sure the name is unique, something like >>> processorId + “ “ + cmd.id in the idExtractor implementation? >>> >> yes, only one, and it must be unique. >> >> Regards, >> Patrik >> >> >>> TIA for the assistance. >>> >>> Regards, >>> >>> Todd >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >> Twitter: @patriknw >> JOIN US. REGISTER TODAY! <http://www.scaladays.org/> >> Scala <http://www.scaladays.org/> >> Days <http://www.scaladays.org/> >> June 16th-18th, <http://www.scaladays.org/> >> Berlin <http://www.scaladays.org/> >> >> -- > >>>>>>>>>> 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. > > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw JOIN US. REGISTER TODAY! <http://www.scaladays.org/> Scala <http://www.scaladays.org/> Days <http://www.scaladays.org/> June 16th-18th, <http://www.scaladays.org/> Berlin <http://www.scaladays.org/> -- >>>>>>>>>> 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.
