Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Received-SPF: pass (athena.apache.org: domain of mdrob@cloudera.com designates
 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANykdubcJUC=sfdY4Ch38a09AyC6PcgC8a8KoxJh-4w2VEF1ZA@mail.gmail.com>
References: 
 <CANykdubcJUC=sfdY4Ch38a09AyC6PcgC8a8KoxJh-4w2VEF1ZA@mail.gmail.com>
From: Mike Drob <madrob@cloudera.com>
Date: Fri, 8 Aug 2014 08:05:20 -0500
Message-ID: 
 <CAFAMeYJ-nLm2rvZgjuzX8pE+Sza-wbrv748EqYwXL9Twq2S3Qg@mail.gmail.com>
Subject: Re: CURATOR-79
To: dev@curator.apache.org
Content-Type: multipart/alternative; boundary=001a11c1f286b3ed6105001ddc4b

--001a11c1f286b3ed6105001ddc4b
Content-Type: text/plain; charset=UTF-8

Explicitly coding for a possible InterruptedException sounds good to me,
but we already know that I prefer (more) diverse Exception types.

I'm not sure I understand what the proposed alternative is?

Mike


On Fri, Aug 8, 2014 at 1:02 AM, Cameron McKenzie <mckenzie.cam@gmail.com>
wrote:

> Guys,
> I've been looking into a fix for CURATOR-79 (
> https://issues.apache.org/jira/browse/CURATOR-79) and have found it to be
> slightly more complicated than initially expected.
>
> The locking recipes are using protected zNodes (i.e the zNode name contains
> a random UUID that is tied to a particular builder instance) for locks,
> which is sensible, but there seems to be an issue with this.
>
> The protected logic basically looks for the cause of failure on a create,
> and if it's connection loss, then it does an ensured deleted on the path it
> was trying to create to ensure that it's removed if it did get created.
>
> For CURATOR-79, and InterruptedException is causing this call to fail when
> waiting for the response from ZK. This means that the protected logic does
> not fire and we end up with an orphaned node.
>
> It's possible with some ugliness to handle this in the InterprocesMutex,
> but I think that maybe it's better fixed in the protected logic. Maybe the
> protected logic could be modified so that it will occur on ConnectionLoss
> or on any non-KeeperException (i.e. InterruptedException). This would cause
> the zNode to be removed if it was created, and would fix this deadlock
> issue.
>
> I would welcome anyone's opinion on the way forward.
> cheers
> Cam
>

--001a11c1f286b3ed6105001ddc4b--