Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BA0FBC3FB for ; Thu, 5 Jun 2014 13:05:02 +0000 (UTC) Received: (qmail 87548 invoked by uid 500); 5 Jun 2014 13:05:02 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 87513 invoked by uid 500); 5 Jun 2014 13:05:02 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 87502 invoked by uid 99); 5 Jun 2014 13:05:02 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jun 2014 13:05:02 +0000 Date: Thu, 5 Jun 2014 13:05:02 +0000 (UTC) From: "Jordan Zimmerman (JIRA)" To: dev@curator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (CURATOR-110) LeaderLatch does not complete if it is started without a connection to ZooKeeper MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CURATOR-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018759#comment-14018759 ] Jordan Zimmerman edited comment on CURATOR-110 at 6/5/14 1:04 PM: ------------------------------------------------------------------ This change has exposed an interesting race. TestLeaderLatch.testWaiting() is intermittently failing because the initial CONNECTED state change can get processed after the initial reset() causing the latch to throttle (i.e. show leader and not-leader in quick succession). It's not really a bug but makes using it harder as the test shows. was (Author: randgalt): This change has exposed an interest race. TestLeaderLatch.testWaiting() is intermittently failing because the initial CONNECTED state change can get processed after the initial reset() causing the latch to throttle (i.e. show leader and not-leader in quick succession). It's not really a bug but makes using it harder as the test shows. > LeaderLatch does not complete if it is started without a connection to ZooKeeper > -------------------------------------------------------------------------------- > > Key: CURATOR-110 > URL: https://issues.apache.org/jira/browse/CURATOR-110 > Project: Apache Curator > Issue Type: Bug > Components: Recipes > Affects Versions: 2.5.0 > Reporter: Cameron McKenzie > Priority: Minor > Labels: connection, latch, leader > Original Estimate: 24h > Remaining Estimate: 24h > > Given the following conditions: > 1.) No connection is available to ZK > 2.) A LeaderLatch is created and started > 3.) All retries for the leader latch creating its ephemeral zNode have been exhausted. > At this point the LeaderLatch will not begin functioning correctly when a connection is established. This is due to it ignoring 'CONNECTED' connection state events (it only handles RECONNECTED events). > The fix should simply be a case of making the state handling for CONNECTED and RECONNECTED the same. -- This message was sent by Atlassian JIRA (v6.2#6252)