hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vinod Johnson <Thomas.John...@Sun.COM>
Subject Re: Simpler ZooKeeper event interface....
Date Fri, 09 Jan 2009 16:15:39 GMT

>
>>> In the case of an active leader, L continues to send commands 
>>> (whatever) to the followers. However a new leader L' has since been 
>>> elected and is also sending commands to the followers. In this case 
>>> it seems like either a) L should not send commands if it's not 
>>> sync'd to the ensemble (and holds the leader token) or b) followers 
>>> should not accept commands from non-leader (only accept from the 
>>> current leader). a) seems the right way to go; if L is disconnected 
>>> it should stop sending commands to the followers, if it's resync'd 
>>> in time it can
>
>> Seems to make sense in this particular case (I had some other cases 
>> in mind that I'm not so sure about though)
>
> Feel free to discuss...
>
>
The thought is not that well formed, so perhaps it does not warrant much 
discussion ... This is more a realization that as far as the leader 
election recipe goes, if *in general* one wants to guarantee not having 
multiple leaders at the same time, certain assumptions have to made 
about timely reception and processing of events. So naively, if I wanted 
to use the recipe to ensure that only one system owns an IP address at 
any given time, I think there would be no way to guarantee it without 
making some assumptions about timing. In retrospect, this should have 
been obvious. In practice it may be simple enough to work around these 
problems (I actually think now that in my case an 'at least once' queue 
is more appropriate). Any way, like I said half baked thoughts ..


Mime
View raw message