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.
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 [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.
