On Monday, June 9, 2014 4:19:46 PM UTC-7, Luis Medina 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?
>
Yes and no. I don't use the akka built in capabilities for this but the
end result is pretty much the same. I create a ring of actors, and then
have a helper that wraps actorseletction that lets me specify an id to hash
with when I lookup the actor ref. And that is hooked into the cluster
events.
> 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;
>
> }
>
>
> 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.
>
>
> So I do almost exactly this setup right now (minus the watchdog) for a
number of things, it's a very useful pattern. I have an entire distributed
persistence layer built using that.
For the bots though ya I needed to make sure they could come back up on
their own more or less. One problem with not having a local controller
(even if you had a global watchdog) is the ticks. Sending out 10,000
messages every 100ms from a single actor to remote actors results in the
ticks being less accurate.
I do like your idea about a receive timeout, never thought of that approach
might come in handy.
Thanks for the input!
Chris
--
>>>>>>>>>> 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.
