Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGQgZQTFJbSNRH2KeG9yU=uzK5MGH8Ks4pcyT5ahTBv3ty+WiA@mail.gmail.com>
References: 
 <CAGQgZQSOAU4FSzvjeZvfwx9_3n8GY_LYzB+wNLTJJzK8aB5ooA@mail.gmail.com>
 <CAJwFCa1NuJMEnZqazD-zGRL0kSUWxmsuUWcx_hLU_iVC=T1-nA@mail.gmail.com>
 <CAGQgZQTFJbSNRH2KeG9yU=uzK5MGH8Ks4pcyT5ahTBv3ty+WiA@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Mon, 19 Sep 2011 18:52:34 -0600
Message-ID: 
 <CAJwFCa2sCC9kfcEJp+W+TRtaozThsR76BzW=PDBKrxiAA+3QHg@mail.gmail.com>
Subject: Re: Distributed locks for global barrier synchronization
To: user@zookeeper.apache.org
Cc: hama-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=485b397dd47b448df304ad54e129

--485b397dd47b448df304ad54e129
Content-Type: text/plain; charset=UTF-8

Conceptually, it might be good to have two barriers, one for the beginning
of a computation and one for the end.  The first barrier is guaranteed not
to have the fast finish characteristic because all nodes are already in the
before-start state.

On Mon, Sep 19, 2011 at 6:04 PM, Edward J. Yoon <edwardyoon@apache.org>wrote:

> Thanks.
>
> And, we found this - https://issues.apache.org/jira/browse/ZOOKEEPER-1011
>
> On Thu, Sep 8, 2011 at 3:06 PM, Ted Dunning <ted.dunning@gmail.com> wrote:
> > It might help to have a different znode for synchronization at each
> > iteration.  That way, if slow nodes are still just getting around to
> > deleting the old node, the fast nodes creating their new nodes will not
> > interfere.
> >
> > On Wed, Sep 7, 2011 at 7:01 PM, Edward J. Yoon <edwardyoon@apache.org
> >wrote:
> >
> >> Hi,
> >>
> >> I'm using Zookeeper for global barrier synchronization of Hama BSP
> >> computing engine. Current implementation is based on 'ZooKeeper
> >> Recipes and Solutions'[1] but there's a problem.
> >>
> >> The problem is that, before the last process leaving the barrier
> >> completely, other processors are starting to create their node[2]. So,
> >> that last process hangs forever at "2. if no children, exit" step.
> >> This problem intermittently occurs on high-performance environments.
> >>
> >> Can anyone advise me?
> >>
> >> 1. http://zookeeper.apache.org/doc/trunk/recipes.html
> >> 2.
> >>
> https://issues.apache.org/jira/browse/HAMA-387?focusedCommentId=13037785&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13037785
> >>
> >> --
> >> Best Regards, Edward J. Yoon
> >> @eddieyoon
> >>
> >
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>

--485b397dd47b448df304ad54e129--