Hi Luis,
On Thu, May 22, 2014 at 9:19 PM, Luis Medina <lu4...@gmail.com> wrote:
> Hi Martynas,
>
> Thank you so much for answering my questions. I know it was quite a
> lengthy read. Just got a few follow-up comments/question:
>
> I think I understand sharding now. In doing something like:
>
> ClusterSharding.get(system).start("Worker", Props.create(Worker.class),
> messageExtractor);
>
> you're essentially telling the cluster that you're going to be sharding
> the Worker actor. This doesn't mean that there will be 1 instance of the
> entry running in the cluster because the number of entries of this type is
> determined by the entryId() method in the messageExtractor.
>
No, that would be wrong usage. Martynas found earlier today that we had not
documented that specific thing and therefore created ticket:
https://github.com/akka/akka/issues/15273
The purpose with cluster sharding is that at any point in time there will
only be one entry actor instance for a specific identifier. You send
messages to this identifier, without knowing where it is currently located.
Shards are only groups of entries. A way for the infrastructure to manage a
large number of entries.
Can you please describe what you are trying to solve? I get the feeling
that you might be using the wrong tool.
Cheers,
Patrik
>
> The number of entries (for a particular entry type) that are run in the
> cluster, depending on how entryId() is specified, will likely be dynamic.
> Similarly, the range of values that the shardId() method returns will
> determine the number of shards that are created in the cluster. So in that
> sense, different shards can potentially contain an instance of the same
> entry and thus, an entry doesn't really have a single shard to call its
> home. Also, the maximum instances of the same entry type that can ever be
> running on the cluster will be equal to the number of shards that it has.
>
>
> Now based on my understanding, let me give a slightly different example:
>
> Say I have 4 nodes in my cluster. As you confirmed, I should ideally have
> 40 shards in the cluster.
>
> In order for my entries to be spread out uniformly throughout my cluster,
> the shardId() method for each entry type should produce the same ~40 unique
> id values (else I risk going past the ideal number of shards for my
> cluster). Given this, do you think that a good setup would be something
> like:
>
> public static class Message {
> public int entryId;
> public int shardId;
> public Object data;
>
> public Message(Object data) {
> this.data = data;
> shardId = Random.nextInt();
> entryId = Random.nextInt();
> }
> }
>
> ShardRegion.MessageExtractor messageExtractor = new
> ShardRegion.MessageExtractor() {
> @Override
> public String entryId(Object message) {
> if (message instanceof Message)
> return Integer.toString(message.entryId);
> else
> return null;
> }
>
> @Override
> public Object entryMessage(Object message) {
> if (message instanceof Message)
> return message.data;
> else
> return null;
> }
>
> @Override
> public String shardId(Object message) {
> if (message instanceof Message)
> return Integer.toString(message.shardId % 40); // note the value
> "40" here
> else
> return null;
> }
> }
>
> a) If the values produced by the shardId() method in the MessageExtractor
> are too random,is there a risk in creating too many entries that remain
> idle? I'm guessing this is where Passivation would come into play.
>
> b) Same question as above but this time say that the entry doesn't
> actually receive message but actually pulls them from somewhere
> (essentially using the pulling pattern). Since Passivation only works based
> on messages that are sent to an entry, how might idle entries be handled in
> this case?
>
> c) So from what you said, sending a message to an entry is done through a
> ShardRegion only if you don't know where it is. Otherwise, if you have its
> ActorRef, you can send a message to it using .tell(...) without having to
> go through the ShardRegion.
>
> d) Do the id values for the entries themselves matter since at most there
> would be 1 entry of that type per shard?
>
> e) Is it possible to have a scenario where all of the shards have an entry
> of a particular type running and you send a message to said entry type 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? Should the entryId() also return id values
> that fall in the same range as the number of shards (so in the example
> above I would do mod 40 of the entryId)?
>
> --
> >>>>>>>>>> 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 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
<http://typesafe.com/go-reactive-activator-contest>
--
>>>>>>>>>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
