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;
}
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.
