I like Alsing's solution Only to exercise my neuron:
Another alternative, have a synchronized list of active Id. Many active actors read command from queue. Check if the corresponding entity Id is in the list. If not, add to it, apply the command, remove the id. If the Id is present wait (if the commands for the SAME entity should be processed in order) (I don't like this point) or put the command again in queue (ooops ;-) All the access to the active id list is synchronized I guess you have few collisions The cons: the wait or requeue the command. shared id list, precluding distributed actors (I could imagine a machine by hash slot in Alsing original solution) The pros: in one actor fails, it only affect a command, instead of a group of hashed entities, that could be thousands? It sounds like CQRS + DDD entities to me Angel "Java" Lopez @ajlopez On Wed, Feb 5, 2014 at 7:20 AM, Carsten Saathoff <[email protected]>wrote: > Am Mittwoch, 5. Februar 2014 08:46:55 UTC+1 schrieb Roger Alsing: > >> Lets say we have the following senario >> >> * we have an unbounded number of entities >> * each entity may only process one command at a time >> * each entity only process a few messages occasionally and then idle for >> an undefined amount of time >> >> Spawning an actor for each entity would force us to keep atleast one >> actor per entity in memory all the time. which is expensive since the will >> mostly be idle. >> > > How many entities are we talking about? An actor is pretty small, so > usually having many of them in memory is not such a big deal, except you > are running in a very constrained environment. > > >> What would be the most idiomatic Akka way to deal with this? >> >> Should we instead add an entity Id to each message, and have a custom >> router that directs each message to a pool of actors and create an affinity >> between the entity id and the pooled actor? >> e.g. >> >> someting like: >> var poolIndex = ((IHaveId)message).Id.GetHashCode() % poolSize; >> >> This way, I could direct every message for a specific entity to the same >> underlying worker actor and thus prevent concurrency issues for this entity. >> The worker actor could also fetch the entity on demand and then release >> it once the command completes. >> > > You can use the Consistent Hashing router to achieve exactly that: > http://doc.akka.io/docs/akka/2.2.3/scala/routing.html > > >> Are there other alternatives? >> > > Do these entity actors have any state that needs to be kept in memory? If > not, one option could also be to just spawn a new actor for every command, > or to keep them alive for a while and then terminate them (using > ReceiveTimeout e.g.). Of course, if they require state that needs to be > gathered from somewhere, this is probably not a very good solution. > > best > > Carsten > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> 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/groups/opt_out. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
