Implement deployment of "singleton" clustered actors from akka.conf
- AOT deployment, go through the akka.conf and create and deploy all actors marked as "singleton"
- Address should not be unique anymore. Should be renamed to DeploymentHandle.
- We change actorOf(... address) to do a lookup on the address and if it fails throw an exception
Leave a comment
on 2011-08-12 00:56 *
By Jonas Bonér
Component changed from None to cluster
Description changed from Have 2 different scenarios:... to * AOT deployment, go throug...
Summary changed from Implement Deployment of clustered actors from akka.conf to Implement deployment of "singleton" clustered actors from akka.conf
singleton means something in a certain scope.
A traditional singleton in Java has the scope of a class loader. In a 'basic' program this would lead to a single instance in the jvm. For webapplications, this isn't the case, unless some crappy unified classloader is used, so it has the scope of 'application' Each application gets his own instance of the singleton.
In Akka currently we mean with the singleton: cluster scope. But I can imagine that for certain services, e.g. a scheduler actor, it would be perfectly allright to give it a jvm/classloader scope.
So some of the possible scopes are:
- prototype (so no scope at all)
- cluster scope
- jvm/classloader scope
And I can imagine that you even want in some cases an 'operation/request' scope..
So imho we need to think about the different scopes in the system and come up with a much more powerful solution. We don't need to implement it for this task, but imho it is wise to know in which direction this very likely is going to evolve. So that we can make the right choices..
A traditional singleton in Java has the scope of a class loader. In a 'basic' program this would lead to a single instance in the jvm. For webapplications, this isn't the case, unless some crappy unified classloader is used, so it has the scope of 'application' Each application gets his own instance of the singleton.
In Akka currently we mean with the singleton: cluster scope. But I can imagine that for certain services, e.g. a scheduler actor, it would be perfectly allright to give it a jvm/classloader scope.
So some of the possible scopes are:
- prototype (so no scope at all)
- cluster scope
- jvm/classloader scope
And I can imagine that you even want in some cases an 'operation/request' scope..
So imho we need to think about the different scopes in the system and come up with a much more powerful solution. We don't need to implement it for this task, but imho it is wise to know in which direction this very likely is going to evolve. So that we can make the right choices..
Updating tickets (#620, #679, #725, #750, #752, #753, #754, #763, #789, #870, #893, #922, #953, #954, #971, #977, #983, #985, #987, #991, #1026, #1045, #1051, #1060, #1061, #1084, #1098, #1099, #1133, #1134, #1135, #1136, #1137, #1194, #1225, #1226, #1243, #1245, #1247, #1248, #1254, #1261, #1300, #1317, #1391, #1412, #1791, #1793, #1901, #1908, #1911, #1912, #1913, #1914, #1915, #1916, #1917, #1922, #1983, #1987, #1996, #1997, #1998, #2066, #2077, #2105, #2117, #2133, #2143, #2149, #2151, #2152, #2153, #2155, #2157, #2158, #2159, #2160, #2161, #2162, #2163, #2164, #2165, #2167, #2171, #2175, #2176, #2177, #2180, #2182, #2184, #2185, #2193, #2199, #2202, #2204, #2206, #2207, #2209, #2210)