Hi Martynas, The number of distinct entryId values determines the number of workers you > are going to have. And the number of ditinct shardId values determines the > number of shards (groups of workers which are managed independently) that > you are going to have.
This makes sense. So ideally, the number of shards in your cluster should be a factor of 10 greater than the number of nodes. Given that, if say I have 10 shards in my cluster, is it good that I have as many workers? Or is this completely based on how much you want to scale? If I'm trying to scale the functionality of a worker, currently I was thinking of having each worker instantiate a cluster-aware router whose routees could handle the heavy lifting. Would it be better instead to get rid of the router, have each worker implement the logic that was in the routees, and then use sharding to scale the worker? Also, is it possible to have a scenario where all of your shards have an entry of a particular type running (each with a different entryId) and you send a message to the entry type but with an entryId that doesn't match any of the ids of the entries that are currently running (ie. There are 10 shards, each one running an entry with an id value that ranges between 1-10, and you send a message with an id value of 11)? What would happen? -- >>>>>>>>>> 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.
