#1260
- Created on2011-10-04 19:00
- Reported by
- StatusNew
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
Allocation and Migration Strategy for clustered actors
From user:
"Another important aspect of this is how actors should be redistributed in the cluster over time. In the example of the big tournament above the tables should be spread-out across the cluster initially, but as players are eliminated (and the number of table actors decrease) more and more tables should be moved closer to the tournament actor. This, IMO, describes some kind of `dynamic migration strategy` which would need to be defined using application-specific rules (or, once again, by setting up dynamic rules for how to allocate actors based on the hierarchy)."
Need to discuss if it makes sense and if so how to do it.
"Another important aspect of this is how actors should be redistributed in the cluster over time. In the example of the big tournament above the tables should be spread-out across the cluster initially, but as players are eliminated (and the number of table actors decrease) more and more tables should be moved closer to the tournament actor. This, IMO, describes some kind of `dynamic migration strategy` which would need to be defined using application-specific rules (or, once again, by setting up dynamic rules for how to allocate actors based on the hierarchy)."
Need to discuss if it makes sense and if so how to do it.
Leave a comment
on 2011-10-04 19:00 *
By Jonas Bonér
Description changed from From user:
Another ... to From user:
"Another impor...
I'm the requester of this feature - so here's some more reasoning about why this makes sense (for us):
It would be great if the actor allocation and execution across the cluster could be optimized depending on the use-case or application.
Our scenario is the one Jonas describes: During execution of a tournament the optimized actor distribution across the cluster changes over time. At first (with many actors) it makes sense to utilize all nodes to share the load/risk - but as actors are stopped (more and more tables are removed from the tournament) it makes more sense to migrate actors closer together (to avoid network overhead/latency and to minimize the number of affected tournaments if a node should crash).
So this requires a way to plugin a custom migration strategy for actors. Not sure exactly what the best level of abstraction for this is - but this might be one:
This would mean that as long as the number of direct child-actors of an 'my-actor' are below 5 they would all be allocated/migrated-to the same node as their parent. If the number of child-actors gets above 5 the extra actors would be allocated/moved to other nodes in the cluster.
Another issue (#1259) was created to capture the (static) requirement that a certain actor would always be spawned/started at the same node as its 'parent'. Using a configuration like the above would make it possible to achieve that behavior using this mechanism. Thus the real name of this feature would perhaps be "Allocation and Migration Strategy".
It would be great if the actor allocation and execution across the cluster could be optimized depending on the use-case or application.
Our scenario is the one Jonas describes: During execution of a tournament the optimized actor distribution across the cluster changes over time. At first (with many actors) it makes sense to utilize all nodes to share the load/risk - but as actors are stopped (more and more tables are removed from the tournament) it makes more sense to migrate actors closer together (to avoid network overhead/latency and to minimize the number of affected tournaments if a node should crash).
So this requires a way to plugin a custom migration strategy for actors. Not sure exactly what the best level of abstraction for this is - but this might be one:
akka {
actor {
deployment {
my-actor {
cluster {
migrate-to-local-threshold = 5
/* or: migrate-to-local-threshold-strategy = com.foo.CustomThresholdValueProvider */This would mean that as long as the number of direct child-actors of an 'my-actor' are below 5 they would all be allocated/migrated-to the same node as their parent. If the number of child-actors gets above 5 the extra actors would be allocated/moved to other nodes in the cluster.
Another issue (#1259) was created to capture the (static) requirement that a certain actor would always be spawned/started at the same node as its 'parent'. Using a configuration like the above would make it possible to achieve that behavior using this mechanism. Thus the real name of this feature would perhaps be "Allocation and Migration Strategy".
on 2011-10-20 17:12 *
By Jonas Bonér
Component changed from None to cluster
Summary changed from Discuss adding a dynamic migration strategy for actors to Allocation and Migration Strategy for clustered actors
Solved with clustering in 'Rollins'
I see this feature have been marked as a duplicate (and pushed to the 'Rollins' release).
Will this feature be implemented as described in this issue - or will the allocation/migration strategies work according to a different philosophy? Either way - is there a duplicating issue# that I can track to monitor this feature? :)
Will this feature be implemented as described in this issue - or will the allocation/migration strategies work according to a different philosophy? Either way - is there a duplicating issue# that I can track to monitor this feature? :)
It is actually not a duplicate. I mixed it up with something else. Opening again.
But it won't be scheduled for the upcoming next releases. Might come back to this one later.
But it won't be scheduled for the upcoming next releases. Might come back to this one later.
on 2012-05-25 14:27 *
By Jonas Bonér
Milestone changed from Rollins to Backlog
Priority changed from Low (4) to Normal (3)