Hi Jordan,

Although the Curator version does not work, I know what is the problem in
my original implementation now. Thanks for your suggestions all the same.


2013/12/17 Jordan Zimmerman <[email protected]>

> Well, there are tests for it. Other than that, can you provide a sample
> that doesn't work?
>
> -Jordan
>
> On Dec 16, 2013, at 5:05 PM, mdzfirst mdzfirst <[email protected]> wrote:
>
> > Hi Jordan,
> >
> > I have tried InterProcessMutex in Curator recipe. Sometimes when a
> process
> > attempts to revoke a locked mutex, the revocationRequested() function of
> > the mutex holder is not called. Any idea why this could happen? Are there
> > any limitation in Curator implementation, such as revocation times or
> > frequency?
> >
> > Thanks and best wishes,
> > mdzfirst
> >
> >
> > 2013/12/15 Jordan Zimmerman <[email protected]>
> >
> >> Are you using a JVM language? Curator already has a revocable lock
> recipe.
> >>
> >>
> >>
> http://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessMutex.html
> >>
> >> -Jordan
> >>
> >> On Dec 15, 2013, at 8:28 AM, mdzfirst mdzfirst <[email protected]>
> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I would like to implement a 'preemptible' mutex with the WriteLock
> >> example
> >>> in the recipe. My method is like this.
> >>>
> >>> 1. Acquire the WriteLock and get the resources
> >>> 2. Set a watch on the lock's root node with getChildren() repeatedly,
> >> using
> >>> a separate ZooKeeper client
> >>> 3. If only one child (self) is found, sleep
> >>> 4. The callback function only wakes up the main thread
> >>> 5. If the watch is triggered and > 1 children are found, release the
> >>> resources and unlock the WriteLock
> >>>
> >>> In my design, I will execute the jar multiple times. Each time a new
> one
> >> is
> >>> started, the old one should be forced to release the mutex. It works.
> The
> >>> first execution does stop. However, the second process seems to lose
> its
> >>> watch on the first one, because the callback function I passed to the
> >>> WriteLock object is never evoked. The callback function is used to
> >>> synchronize the locking request and is thus very important.
> >>>
> >>> Can anyone see any flaws in my design, or provide a different way that
> >>> works? Thanks~
> >>>
> >>> Best regards,
> >>> mdzfirst
> >>
> >>
> >
> >
> > --
> > Best wishes,
> >
> > --------
> >
> > Ma Dongzhe
> > Department of Computer Science and Technology
> > Tsinghua University
> > Beijing 100084, P.R. China
>
>


-- 
Best wishes,

--------

Ma Dongzhe
Department of Computer Science and Technology
Tsinghua University
Beijing 100084, P.R. China

Reply via email to