curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chao chu <chuchao...@gmail.com>
Subject Re: Leader Latch recovery after suspended state
Date Mon, 10 Mar 2014 16:37:22 GMT
*>>> Theoretically, you could assume you are still leader during SUSPENDED
if the session timeout hasn't elapsed.*

yep, this is exactly what I want to point out, so far, the only drawback I
can think of is that if the latch1 <--> zk1 connection loss was really
caused due to the client of latch1 (process crash, etc.), we have a time
window (up to session timeout value) where no leader can be used actually.

I will try to clone a LeaderLatch and adapt it to my expected behavior
mentioned for our use case. But I am not sure if you are fine to accept it
as an alternative and leave the choice up to the user? If it's 'yes',
what's your suggested way to do this? it's likely there will be a lot of
duplicate code if adding it as another leader election recipe. maybe we can
open a way to let the default 'listener' in leader latch can be overrided,
there we can override the 'handleStateChange'.

Thanks a lot for your time on this anyway :)


On Tue, Mar 11, 2014 at 12:08 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Otherwise, at least for LeaderLatch, we lose the advantage to have the
> distinguish between ConnectionLossException and SessionExpiredExpection.
>
> Session expired is only generated when the client successfully reconnects
> to the cluster. It's not really a very useful bit of information.
> Theoretically, you could assume you are still leader during SUSPENDED if
> the session timeout hasn't elapsed. But, this is really trying to be too
> clever IMO.
>
> -JZ
>



-- 
ChuChao

Mime
View raw message