*>>> 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 < [email protected]> 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
