On Tue, Jun 10, 2014 at 1:19 AM, Luis Medina <[email protected]> wrote:
> I don't think you state this anywhere but based on the fact that you use
> consistent hashing, are your bots running in a cluster-aware, consistent
> hashing router?
>
> One other solution that I thought of was to shard your bots using their
> id's for the entryId values which effectively removes the need for
> individual bot controllers. This might look something like:
>
> ClusterSharding.get(system).start("Bots", BotActor.props(), new
> MessageExtractor());
>
>
> where your MessageExtractor could be:
>
> public class MessageExtractor implements ShardRegion.MessageExtractor {
> @Override public String entryId(Object message) { if (message
> instanceof ShardMessage) { return ((ShardMessage)
> message).entryId(); } else { return null; } }
> @Override public Object entryMessage(Object message) { if (message
> instanceof ShardMessage) { return ((ShardMessage)
> message).entryMessage(); } else { return message; }
> } @Override public String shardId(Object message) { if
> (message instanceof ShardMessage) { return ((ShardMessage)
> message).shardId(); } else { return null; } }}
>
>
> and the ShardMessage class is:
>
> public class ShardMessage implements Serializable { private Object
> message; private String entryId; private String shardId; public
> ShardMessage(Object message, String entryId, String shardId) {
> this.message = message; this.entryId = entryId; this.shardId =
> shardId; } public String entryId() { return entryId; }
> public String shardId() { return shardId; } Object
> entryMessage() { return message; }}
>
>
> Then when you create your bots, assuming your cluster has say 10 nodes,
> this might look like:
>
> ActorRef region = ClusterSharding.get(context().system()).shardRegion("Bots");
>
> int shardId = new Random().nextInt() % 100; // As a rule of thumb, the number
> of shards should be a factor ten greater than the planned maximum number of
> cluster nodes.
>
>
> for(String id : botIds) { region.tell(new ShardMessage("tick", id,
> Integer.toString(shardId)), self());
>
> shardId = new Random().nextInt() % 100;
>
> }
>
>
> Luis, thank you for sharing your experience of using Cluster Sharding.
There is one thing that I would like to clarify here. The shardId must
always be the same for a given entryId. Normally the entries have know
identifiers, such as username of the the bots. This identifier is the
destination address for the messages. Cluster Sharding takes care of
delivering the messages to the right location. In the analogy with postal
service the entry id is the full address, and the shard id is the zip code.
That means that the shard id should be derived from the entry id (or the
same stable properties), e.g. shardId =
String.valueOf(Math.abs(botId.hashCode) % 100)
Cheers,
Patrik
If any of your nodes go down, the bots on them would simply get moved
over to the nodes that are still up. If you care about preserving the
state your bots were in could also make them Persistent. The only
caveat here is that sharded actors are not created automatically, they
are created on-demand when the first message is sent to them. This
means that you're going to need to have some sort of WatchDog that
takes care of pinging all of your bots. The WatchDog could itself be a
singleton which would keep a list of all of the bots that should be up
which it uses to ping them with the "ticks" that you mentioned. I know
this goes against the fact that you don't want a sort master-slave
setup, perhaps there is another way around this, not sure. Also, in
the case that you wanted to get rid of bots by removing them from the
list that the WatchDog has, you could have each BotActor implement a
Receive timeout that it uses to shut itself down if it hasn't received
a "tick" after a specified amount of time.
>
>
>
>
> --
> >>>>>>>>>> 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
<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.
