1412 would happen if you only do gets, 1367 is summarized here: https://issues.apache.org/jira/browse/ZOOKEEPER-1367?focusedCommentId=13195252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13195252 The basic issue being that the restarted follower knows about the znodes but not the sessions, if that follower later becomes the leader, when it would never expire the session (and therefore never remove the znodes).
Patrick On Thu, May 31, 2012 at 5:42 PM, Jordan Zimmerman <[email protected]> wrote: > My major concern is 1412 and 1367. We're seeing a scenario where it appears > that watches aren't triggered and/or ephemeral nodes are not deleted on > session expiration. In particular, we have 30-ish clients participating in a > lock recipe. We kill two ZK instances to get a quorum failure. When the > instances are brought back up, the clients are blocked. It very well could be > Curator's lock code, but I'm wondering if it's one of these bugs. > > -JZ > > > >>________________________________ >> From: Patrick Hunt <[email protected]> >>To: [email protected]; Jordan Zimmerman <[email protected]> >>Sent: Thursday, May 31, 2012 5:36 PM >>Subject: Re: 3.3.4 client vs 3.3.5 client >> >>1309? >> >>On Thu, May 31, 2012 at 5:29 PM, Jordan Zimmerman >><[email protected]> wrote: >>> http://zookeeper.apache.org/doc/r3.3.5/releasenotes.html >>> >>> >>> The bugs fixed in 3.3.5 seem to apply only to the server, but it isn't >>> totally clear. If I were using a 3.3.4 client on a 3.3.5 server might I >>> still see any of these issues? >>> >>> -JZ >> >> >>
