curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akos Gyimesi (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CURATOR-220) LOST state is sometimes not reported to ConnectionStateListener
Date Fri, 15 May 2015 20:37:59 GMT

     [ https://issues.apache.org/jira/browse/CURATOR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Akos Gyimesi updated CURATOR-220:
---------------------------------
    Description: 
I used iptables to drop all outgoing packets to ZooKeeper, and logged the connection state
changes. Most of the time I got only CONNECTED->SUSPENDED->RECONNECTED states, even
though the ZooKeeper session expired and the ephemeral nodes of the session disappeared. (I
expected CONNECTED->SUSPENDED->LOST->RECONNECTED)

According to CURATOR-185 this may not be a bug because Curator connection states are not in
1-to-1 relation with ZooKeeper connection events. However, it causes problems in the LeaderSelector
recipe (and possibly in others): without the LOST event the leader will never know if it really
lose leadership or not. If it does not resign leadership at the SUSPENDED event (which is
recommended, but not required according to the docs) the session will be in leader state forever.

See the following gist: https://gist.github.com/gyim/caea1b73cc8fa8f6997b
The code tests the LeaderSelector recipe, but the behavior is the same with a simple ConnectionStateListener.

Tested with Curator 2.4.2 and 2.8.0, it probably affects several other versions as well.

  was:
I used iptables to drop all outgoing packets to ZooKeeper, and logged the connection state
changes. Most of the time I got only SUSPENDED and RECONNECTED states, even though the ZooKeeper
session expired and the ephemeral nodes of the session disappeared.

According to CURATOR-185 this may not be a bug because Curator connection states are not in
1-to-1 relation with ZooKeeper connection events. However, it causes problems in the LeaderSelector
recipe (and possibly in others): without the LOST event the leader will never know if it really
lose leadership or not. If it does not resign leadership at the SUSPENDED event (which is
recommended, but not required according to the docs) the session will be in leader state forever.

See the following gist: https://gist.github.com/gyim/caea1b73cc8fa8f6997b
The code tests the LeaderSelector recipe, but the behavior is the same with a simple ConnectionStateListener.

Tested with Curator 2.4.2 and 2.8.0, it probably affects several other versions as well.


> LOST state is sometimes not reported to ConnectionStateListener
> ---------------------------------------------------------------
>
>                 Key: CURATOR-220
>                 URL: https://issues.apache.org/jira/browse/CURATOR-220
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 2.4.2, 2.8.0
>            Reporter: Akos Gyimesi
>
> I used iptables to drop all outgoing packets to ZooKeeper, and logged the connection
state changes. Most of the time I got only CONNECTED->SUSPENDED->RECONNECTED states,
even though the ZooKeeper session expired and the ephemeral nodes of the session disappeared.
(I expected CONNECTED->SUSPENDED->LOST->RECONNECTED)
> According to CURATOR-185 this may not be a bug because Curator connection states are
not in 1-to-1 relation with ZooKeeper connection events. However, it causes problems in the
LeaderSelector recipe (and possibly in others): without the LOST event the leader will never
know if it really lose leadership or not. If it does not resign leadership at the SUSPENDED
event (which is recommended, but not required according to the docs) the session will be in
leader state forever.
> See the following gist: https://gist.github.com/gyim/caea1b73cc8fa8f6997b
> The code tests the LeaderSelector recipe, but the behavior is the same with a simple
ConnectionStateListener.
> Tested with Curator 2.4.2 and 2.8.0, it probably affects several other versions as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message