On Sun, Mar 15, 2015 at 11:02 AM, Ömer Faruk Gül <omergul...@gmail.com>
wrote:

> Thanks Roland, one more question, how do I know that there is a
> convergence? My actor listens for *LeaderChanged* event, I don't directly
> check *cluster.state* so if my actor receives LeaderChanged event, can I
> assume that there is a convergence? Or could there be any other node which
> receives a LeaderChanged event that contains a different node?
>

Yes. For example 5 nodes N1..N5, leader is N1. Network split {N1, N2} {N3,
N4, N5}. On the nodes of the second half you will see LeaderChanged(N3),
because N1 and N2 are unreachable.

In the internal implementation of Akka cluster the leader only performs
certain actions when there is convergence, but that is not something that
is exposed in user API.

Can you describe a bit more what you are trying to solve and we can perhaps
give you some advice on what tool to use.

You mentioned earlier that you are broadcasting membership changes from one
node, but that doesn't make much sense to me without additional context.
Why can't each node subscribe to those changes itself?

/Patrik


>
>
> On Sunday, March 15, 2015 at 7:08:19 PM UTC+2, rkuhn wrote:
>>
>> Hi Ömer,
>>
>> we should probably be a bit more precise: while it is true that “leader”
>> is only defined as the lowest element of some list that is locally computed
>> on all nodes, and there might be different views on who the leader is, it
>> should be noted that that does not matter since the leader only takes
>> action when there is convergence, in which case all nodes agree upon who
>> the leader is.
>>
>> Your use-case might be better solved using a Singleton (but that can be
>> down for a short time period after a failure) or even akka-data-replication.
>>
>> Regards,
>>
>> Roland
>>
>> 15 mar 2015 kl. 04:05 skrev Ömer Faruk Gül <omerg...@gmail.com>:
>>
>> Hi,
>>
>> I'm working on an akka cluster project, and I have read that there can be
>> multiple leaders in a cluster, and in my project when is an action to be
>> taken taken across the cluster, the leader simply handles that. So is that
>> a wrong approach, and should I use singleton actor in this case, or is
>> there any other way?
>>
>> My use case is, I have a map data, that changes every time when a new
>> node is added or removed (or unreachable). This data has to be updated by
>> only one node and will be broadcasted to other nodes. And in my project
>> this is the leader's responsibility. But if multiple leaders are possible
>> it could be a mess.
>>
>> On Tuesday, March 10, 2015 at 7:05:03 PM UTC+2, Patrik Nordwall wrote:
>>>
>>>
>>>
>>> On Tue, Mar 10, 2015 at 4:38 PM, michaels <michael...@atos.net> wrote:
>>>
>>>>
>>>>
>>>> On Tuesday, March 10, 2015 at 4:17:10 PM UTC+1, Patrik Nordwall wrote:
>>>>>
>>>>> What was puzzling me was:
>>>>> Cluster Node [akka.tcp://...Node4...] - Marking node(s) as REACHABLE
>>>>> [Member(address = akka.tcp://....Node1..., status = Up)]
>>>>>
>>>>> but looking at the code revealed that this is only an notification
>>>>> that Node4 thinks that Node1 is reachable again. The ReachableMember event
>>>>> is fired when all thinks it is reachable again, and that will not happen
>>>>> until Node3 is back in business or removed.
>>>>>
>>>>>
>>>> So...while being still in this status
>>>> - Node 1: MemberStatus=Up, Leader = 1 / Unreachable = Node 3
>>>> - Node 2: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>>>> - Node 4: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>>>>
>>>> ...is it a problem for Node 2 and Node 3 if Node 1 has the cluster
>>>> singleton?
>>>>
>>>> I mean, from the state above, i suppose Node 1 will be able handle
>>>> application tasks (which require cluster singleton actions) perfectly.
>>>>
>>>> But what about Node 2 and Node 4? Will they use the cluster singleton
>>>> of Node 1, even if they have Node 1 in their Unreachable List?
>>>>
>>>
>>> Yes, cluster singleton decisions are not based on unreachability
>>> information at all.
>>> /Patrik
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> --
>>>> >>>>>>>>>> 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 akka-user+...@googlegroups.com.
>>>> To post to this group, send email to akka...@googlegroups.com.
>>>> 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
>>>
>>> [image: Scala Days] <http://event.scaladays.org/scaladays-sanfran-2015>
>>>
>>>
>> --
>> >>>>>>>>>> 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 akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> *Dr. Roland Kuhn*
>> *Akka Tech Lead*
>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
>> twitter: @rolandkuhn
>> <http://twitter.com/#!/rolandkuhn>
>>
>>  --
> >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> 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

[image: Scala Days] <http://event.scaladays.org/scaladays-sanfran-2015>

-- 
>>>>>>>>>>      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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
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