On Mon, Jun 2, 2014 at 1:10 PM, Eduardo Fernandes <[email protected]> wrote:
> Many Thanks Patrik. > > I'm afraid that if I manage the actors directly I'll lose all the cluster > benefits, include spreading out the mapping objectId -> physical node. > That would not change. The ClusterSharding extension is "only" creating exactly the same actors for you, in a convenient way. I understand that you think it is overwhelming to create these actors yourself, but it is possible (and the reason why the props methods are public). > I think that I can reduce the problem to a case where I could avoid the > creation of new actors in a particular node in the cluster and then, after > all actors are virtually inactive, turn the node down. > > I don't know where is the mapping of entryId -> physical node. > > Could I override the distribution logical somehow so I could control in > which physical node the actor will be instantiated in the cluster? That > would be perfect. I'd overridden the mapping using the sharding policy with > AbstractShardAllocationStrategy inheriting > from LeastShardAllocationStrategy but I couldn't find where adjust the way > the cluster assign physical nodes to the particular sharding entry. > Yes, that is done by the information returned by the AbstractShardAllocationStrategy. The passed in currentShardAllocations contains the ActorRefs of the ShardRegion actors, and you could use the addresses of these to decide which nodes to use. You must somehow correlate those addresses with the addresses of the cluster members if you want to use the cluster role information. The AbstractShardAllocationStrategy does not allocate locations for individual entries. That is always done on a group of entries, a.k.a. shard. You define the mapping between entry ids (messages) and shards in the MessageExtractor. /Patrik > > Many thanks, Patrik, for your help. > > Regards. > > > > El lunes, 2 de junio de 2014 10:24:34 UTC+2, Patrik Nordwall escribió: > >> Hi Eduardo, >> >> The ClusterSharding extension supports configuration of one role to use a >> subset of nodes, but that is not what you are looking for. Instead of using >> the ClusterSharding extension you may start the actors yourself and thereby >> specify the roles. >> See: >> ShardCoordinatorSupervisor.props >> ShardCoordinator.props >> ShardRegion.props >> >> Note that the ShardCoordinatorSupervisor is supposed be started with >> a ClusterSingletonManager. See here: https://github.com/akka/ >> akka/blob/v2.3.3/akka-contrib/src/main/scala/akka/contrib/ >> pattern/ClusterSharding.scala#L360 >> >> Cheers, >> Patrik >> >> >> -- > >>>>>>>>>> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw <http://typesafe.com/go-reactive-activator-contest> -- >>>>>>>>>> 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.
