I don't think that this is an issue now since you can use roles and "spread 
out" the cluster-singletons that way.

That the cluster-singleton can be made to only start on a node with a 
specific role is perfectly clear from the documentation. What  I think that 
what could be improved is this part:

> The singleton actor is always running on the oldest member, which can be 
> determined by Member#isOlderThan. This can change when removing that 
> member from the cluster. Be aware that there is a short time period when 
> there is no active singleton during the hand-over process.
>
It probably should say something like:
The singleton actor is always running on the on the oldest member with 
specified role ... 
To avoid getting stupid questions from people like me :)

Thanks for helping me out!



On Friday, April 3, 2015 at 6:04:36 PM UTC+2, Patrik Nordwall wrote:
>
>
>
>
> 3 apr 2015 kl. 17:34 skrev Akka Team <[email protected] <javascript:>>:
>
> Hello Olle,
>
> Are there any way of not having all cluster-singleton actors running on 
>> the same node ( the leader node of the cluster ) in case that a service 
>> needs to be migrated to another node because of other reasons than a node 
>> is down ( out of disk space or something like that ).
>
> It does not have to be running on the cluster leader - it can run on 
> "oldest node that has a given role", it's documented here:
> http://doc.akka.io/docs/akka/current/contrib/cluster-singleton.html 
>
> So you can have roles like "backend" or "cpu-heavy" and then the singleton 
> would be running on the oldest cluster member that contains each its 
> required role.
> We do not support very dynamic moving of singletons around as you seem to 
> be asking for.
> Singletons are usually used for light "master" or "scheduler" Actors, and 
> the actual work would be performed by some sharded workers.
>
> Do you feel you have a strong use-case for it or are just wondering if 
> it's possible?
>
>
> I noticed that you can use roles for the cluster-singleton, what happens 
>> if a new leader is elected but without the roles needed for a particular 
>> cluster singleton would that service be spun up on a non-leader node ?
>
> The cluster "leader" is not what decides where the singleton is being run. 
> The singleton is running on "oldest node, that matches it's role 
> requirements".
>
> Yes, if you do not require any roles, this requirement matches with the 
> node that we call the cluster leader, but as you see the singleton may (and 
> often will) run on non-leader nodes.
>
>
> Let me clarify the terminology. What we call cluster leader is actually 
> the node with the lowest address (sorted by hostname:port). That is not the 
> same as the oldest node. Singleton runs on the oldest node (with matching 
> role requirements).
>
> This is not the first time this comes up. Is the documentation wrong 
> somewhere?
>
> /Patrik
>
>
> Hope this helps! 
>
>
> -- Konrad
>
> On Tue, Mar 31, 2015 at 8:38 AM, <[email protected] <javascript:>> 
> wrote:
>
>> Hi,
>>
>> A couple of questions regarding the cluster-singleton functionality:
>>
>>    - Are there any way of not having all cluster-singleton actors 
>>    running on the same node ( the leader node of the cluster ) in case that 
>> a 
>>    service needs to be migrated to another node because of other reasons 
>> than 
>>    a node is down ( out of disk space or something like that ).
>>    - I noticed that you can use roles for the cluster-singleton, what 
>>    happens if a new leader is elected but without the roles needed for a 
>>    particular cluster singleton would that service be spun up on a 
>> non-leader 
>>    node ?
>>    
>> Thanks, Olle 
>>
>>
>>
>>  -- 
>> >>>>>>>>>> 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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>  
> -- 
> >>>>>>>>>> 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] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
>>>>>>>>>>      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.

Reply via email to