curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jędrzej Dąbrowa <>
Subject Re: ConnectionStateListener not called on lost quorum
Date Tue, 13 Sep 2016 07:45:11 GMT
I use 2.10.0 because I need to connect to zk 3.4.8. Retry loop does not 
seem be executed - I've tested that with 'new RetryNTimes(0, 0)' and it 
still timeouts after about one minute, which I reckon is default session 
timeout. That seems to be caused by zk CP property, so in face of quorum 
loss instead of failing it just awaits majority to be restored. So my 
exact question is: given circumstances described, is there any 
possibility to get notified about quorum loss asynchronously?

On Tuesday13/09/16 09:2459, Cameron McKenzie wrote:
> Which version of curator are you using? In 2.x a LOST even will not 
> occur until the retries specified by your retry policy occur. In 3.x 
> the default behavior is to simulate the LOST state after being in a 
> suspended state for longer than the session timeout.
> On 13 Sep 2016 5:15 PM, "Jędrzej Dąbrowa" < 
> <>> wrote:
>     I connect through Curator to an ensemble of 3 zk (testing)
>     servers. Any time zk connection is lost I would like to return
>     appropriate error code to the user instead of calling zk. I do
>     this by monitoring connection state with ConnectionStateListener.
>     It works with various test scenarios, but when 2 out of 3 servers
>     are killed (and quorum is lost) Curator emits no such events and
>     the first call to ZK after quorum loss results in timeout with
>     org.apache.curator.CuratorConnectionLossException: KeeperErrorCode
>     = ConnectionLoss. Is there a possibility to get notified by
>     Curator about quorum loss prior to executing any call, prevent
>     long timeout and use fail-fast approach?
>     Thank you,
>     Jed

View raw message