Return-Path: 
 <user-return-3794-apmail-zookeeper-user-archive=zookeeper.apache.org@zookeeper.apache.org>
X-Original-To: apmail-zookeeper-user-archive@www.apache.org
Delivered-To: apmail-zookeeper-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E9A4D96C8
	for <apmail-zookeeper-user-archive@www.apache.org>;
 Thu, 22 Sep 2011 02:23:42 +0000 (UTC)
Received: (qmail 19263 invoked by uid 500); 22 Sep 2011 02:23:42 -0000
Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org
Received: (qmail 19224 invoked by uid 500); 22 Sep 2011 02:23:42 -0000
Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@zookeeper.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@zookeeper.apache.org>
List-Post: <mailto:user@zookeeper.apache.org>
List-Id: <user.zookeeper.apache.org>
Reply-To: user@zookeeper.apache.org
Delivered-To: mailing list user@zookeeper.apache.org
Received: (qmail 19207 invoked by uid 99); 22 Sep 2011 02:23:42 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2011 02:23:42 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [209.85.161.170] (HELO mail-gx0-f170.google.com)
 (209.85.161.170)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2011 02:23:35 +0000
Received: by gxk10 with SMTP id 10so1695421gxk.15
        for <multiple recipients>; Wed, 21 Sep 2011 19:23:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.147.17.13 with SMTP id u13mr1547476yai.31.1316658192946; Wed,
 21 Sep 2011 19:23:12 -0700 (PDT)
Received: by 10.147.168.11 with HTTP; Wed, 21 Sep 2011 19:23:11 -0700 (PDT)
X-Originating-IP: [1.212.30.211]
In-Reply-To: 
 <CAJwFCa3J0eXt-WWKOuq-zyHVU6SvfTFERpDyZU=1RWY0JSPyNw@mail.gmail.com>
References: 
 <CALXUk3x9-TzOKzEofFA=X0tzH80MSMggDy_bON5T8YksxoEJ0w@mail.gmail.com>
	<69D3016305F9084FBD2C4A0DF189BD5C1777E427BB@GSCMAMP02EX.firmwide.corp.gs.com>
	<CAJwFCa3J0eXt-WWKOuq-zyHVU6SvfTFERpDyZU=1RWY0JSPyNw@mail.gmail.com>
Date: Thu, 22 Sep 2011 11:23:11 +0900
Message-ID: 
 <CALXUk3yEWYLDWqsQm66NuswUz+isbdHvABzuCV8oaVNjuotMUg@mail.gmail.com>
Subject: Re: Creating a znode with SEQUENTIAL_EPHEMERAL mode becomes corrupt
 in case of unstable network
From: =?EUC-KR?B?udq/tbHZKEFsZXgp?= <alex.park@nexr.com>
To: dev@zookeeper.apache.org
Cc: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=000e0cd3839ce1982404ad7e5fe7
X-Virus-Checked: Checked by ClamAV on apache.org

--000e0cd3839ce1982404ad7e5fe7
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: quoted-printable

Ted, Camille
Thanks for your reply.

The property that enables the creation of a znode with SEQUENTIAL_EPHEMERAL
mode is used
in ReadWriteLock  running on our analytics platform.

Hang has been caused by this problem so that we should search any other
solution.

Anyway, I will check out related issues.

Thanks,
Alex

2011/9/21 Ted Dunning <ted.dunning@gmail.com>

> If you cannot tolerate this sort of situation, then the only solution is
> typically to avoid sequential ephemerals.  The problem is that in the
> presence of a flaky network you cannot always tell if a failed create
> actually created the znode in question.  This is because the network may
> have failed after the create succeeded, but before you got the result.  I=
n
> that case, since this is a sequential ephemeral, you can't know if your
> file
> got created because you don't even know the name.  Moreover, scanning
> doesn't help because if you could scan, you probably could have used a
> fixed
> unique name in the first place.
>
> There is a very long standing proposed (nearly complete) solution for thi=
s
> that requires some difficult coding.  See
> https://issues.apache.org/jira/browse/ZOOKEEPER-22
>
> 2011/9/21 Fournier, Camille F. <Camille.Fournier@gs.com>
>
> > This is expected. In cases where the network becomes unstable, it is th=
e
> > responsibility of the client writer to handle disconnected events
> > appropriately and check to verify whether nodes they tried to write
> around
> > the time of these events did or did not succeed. It makes writing a
> > "Generic" client for ZK very difficult (search the mailing list for
> zkclient
> > and you'll read a bunch of convos around this topic). Fortunately, many
> > things that rely on EPHEMERAL_SEQUENTIAL nodes can tolerate some
> duplication
> > of data, so often it's not a huge problem.
> >
> > C
> >
> > -----Original Message-----
> > From: =B9=DA=BF=B5=B1=D9(Alex) [mailto:alex.park@nexr.com]
> > Sent: Wednesday, September 21, 2011 9:16 AM
> > To: dev@zookeeper.apache.org
> > Cc: user@zookeeper.apache.org
> > Subject: Creating a znode with SEQUENTIAL_EPHEMERAL mode becomes corrup=
t
> in
> > case of unstable network
> >
> > Hi, All
> >
> > I met a problem in creating a znode with SEQUENTIAL_EPHEMERAL mode unde=
r
> > unstable network condition.
> >
> > While a client did not receive a message that a sequential node was
> > created,
> > the ensemble has the znode, which is checked at zookeeper dashboard(
> > https://github.com/phunt/zookeeper_dashboard).
> >
> > If the client receives a DISCONNECTED event, it tries to reconnect.
> > Session timeout is 30 seconds.
> >
> > Unstable network condition is made as the following:
> >
> > The grinder agent sends a request of creating a znode of
> > CreateMode. SEQUENTIAL_EPHEMERAL.
> > ZK ensemble has three servers.
> > Each NIC of server is down and up repeatedly;
> > NIC of server1 become down every one minute and sleeps for 9 seconds,
> then
> > up
> > NIC of server2 become down every 2 minute and sleeps for 9 seconds, the=
n
> up
> > NIC of server3 become down every 3 minute and sleeps for 9 seconds, the=
n
> up
> >
> > Is there any idea or related issue?
> >
> > Thanks in advance.
> >
> > Alex
> >
>

--000e0cd3839ce1982404ad7e5fe7--