#994
- Created on2011-07-06 11:43
- Reported by
- StatusDuplicate
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
Allowing config and implementation for 'shared = on/off' for clustered actor
UPDATE: needs discussion. We need the concept of a recipe in the configuration.
Now we have this: If an actor of the same logical address already exists in the registry then just return that, if not create a new one.
BUT: We should be able to define if an actor, even though the same address is used, should be 'shared' as above or not. If not then for each call to 'actorOf[TYPE]("address")' a new parallel actor should be created. In the case of clustered actor then a new ClusterActorRef and X nr of new replicas on other machines should be created. All isolated from the ones created by a subsequent call to 'actorOf[TYPE]("address")'.
It should be possible to configure this both in code through the config passed to 'actorOf' and in the config file.
Now we have this: If an actor of the same logical address already exists in the registry then just return that, if not create a new one.
BUT: We should be able to define if an actor, even though the same address is used, should be 'shared' as above or not. If not then for each call to 'actorOf[TYPE]("address")' a new parallel actor should be created. In the case of clustered actor then a new ClusterActorRef and X nr of new replicas on other machines should be created. All isolated from the ones created by a subsequent call to 'actorOf[TYPE]("address")'.
It should be possible to configure this both in code through the config passed to 'actorOf' and in the config file.
Leave a comment
on 2011-07-06 11:49 *
By pveentjer
Description changed from Now we have this: If an act... to Now we have this: If an act...
I think that the actor configuration should have settings for the 'scope' of an actor. If you always want to have new actors created (e.g. a bank account actor), you give it a prototype scope. If you want to reuse the same set of actors (e.g. the usermanager actor) you give it a singleton scope. So instead of 'shared' name it 'scope' and possible values for the enumeration are 'prototype, request, singleton_per_jvm_singleton_per_cluster etc etc).
Another comments:
Should the explicitly provided configuration override the implicitly provided configuration (so external config file) or should it be the other way around. So either one is the boss.. or the other is.. but it should be clear which one is leading.
Another comments:
Should the explicitly provided configuration override the implicitly provided configuration (so external config file) or should it be the other way around. So either one is the boss.. or the other is.. but it should be clear which one is leading.
on 2011-07-11 11:47 *
By viktorklang
I don't think actorOf should be used as actorFor
on 2011-07-11 11:48 *
By viktorklang
And by that I mean that actorOf always creates a new actor, the deployment config tells us where it should be created.
He Viktor,
we need to talk about it. What I understood of Jonas is that it should be transparent to the end user if he got an already existing actor or gets a new one. Especially of the named version of the actorOf is called:
val ref = Actor.actorOf[EmployeeManager]("employeeManager")
In this case it could be that the employeeManager actor is a singleton on the machine since it isn't correct if more than 1 instance is created.
But lets have the meeting about it instead of doing this asynchronous communication :)
we need to talk about it. What I understood of Jonas is that it should be transparent to the end user if he got an already existing actor or gets a new one. Especially of the named version of the actorOf is called:
val ref = Actor.actorOf[EmployeeManager]("employeeManager")
In this case it could be that the employeeManager actor is a singleton on the machine since it isn't correct if more than 1 instance is created.
But lets have the meeting about it instead of doing this asynchronous communication :)
on 2011-07-20 18:14 *
By Jonas Bonér
Assigned to changed from pveentjer to -none-
Description changed from Now we have this: If an act... to UPDATE: needs discussion. W...
Defined in #1098
Updating tickets (#967, #974, #975, #976, #980, #981, #989, #990, #992, #993, #994, #999, #1000, #1004, #1008, #1011, #1015, #1018, #1022, #1023, #1024, #1025, #1027, #1028, #1029, #1030, #1032, #1033, #1036, #1047, #1053, #1062, #1067, #1068, #1069, #1072, #1075, #1078, #1082, #1102, #1107, #1110, #1111, #1115, #1116, #1121, #1122, #1123, #1124)