curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <m...@speakeasyapp.net>
Subject Re: Reaper/ChildReaper usage
Date Tue, 31 Mar 2015 17:45:10 GMT
I am definitely using 2.7.1 (see below for dependency in pom) and getting the aforementioned
issues 

(ChildReaper /locks/calendar by itself does nothing, addPath /lock/calendar/uuid removes it’s
subdirs but not itself, combo gets error about /lock/calendar/uuid disappearing)


More explicitly what I was doing was:


In initial setup of curator framework I EnsurePath to make /locks/calendar


I then construct a ChildReaper path = /locks/calendar, mode = delete or mode = gone, doesn’t
matter for this error.


During lock release I addPath to the reaper /lock/calendar/uuid. If I do this everything is
whacked but I start getting the endless errors. If I don’t add this, nothing gets reaped.
If I don’t add in #2, the subdirs of /lock/calendar/uuid get reaped but not /lock/calendar/uuid.







<dependency><groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId><version>2.7.1</version>
</dependency>






From: Jordan Zimmerman
Sent: ‎Tuesday‎, ‎March‎ ‎31‎, ‎2015 ‎10‎:‎32‎ ‎AM
To: mike@speakeasyapp.net, user@curator.apache.org





It looks like CURATOR-173 was possibly released in Curator 2.7.1. Scott Blum needs to respond
on this.




-Jordan







On March 31, 2015 at 12:31:54 PM, mike@speakeasyapp.net (mike@speakeasyapp.net) wrote:




 
Confirmed btw that InterprocessMutex is reaped properly. However locks cannot be reentrant
across threads in the same process so I am wondering if I should pull together my own patch
from the ticket?






From: David Kesler
Sent: ‎Tuesday‎, ‎March‎ ‎31‎, ‎2015 ‎10‎:‎17‎ ‎AM
To: user@curator.apache.org






How are you constructing your ChildReaper?  It sounds like you’re constructing a child reaper
using the path of the lock itself and the path the childreaper is watching is getting deleted
(though I’m not sure why).  If you’re planning on having a number of locks of the form
/lock/calendar/uuid1, /lock/calendar/uuid2, etc., you should be creating a single ChildReaper
at startup that uses /lock/calendar as the path for your child reaper.  This will ensure that
the children of /lock/calendar (that is, your uuid locks) will get reaped.  You don’t need
to be adding /lock/calendar/uuid to your child reaper directly.

 

As a side note,  if you’re using InterProcessSemaphoreMutex, there’s currently an issue
with ChildReaper in 2.7 (https://issues.apache.org/jira/browse/CURATOR-173) which should hopefully
be fixed in the next release.  If you can, you may want to consider InterProcessMutex instead.


 



From: mike@speakeasyapp.net [mailto:mike@speakeasyapp.net]
Sent: Tuesday, March 31, 2015 12:57 PM
To: user@curator.apache.org
Subject: Reaper/ChildReaper usage

 



Hi, I’m using the InterProcessSemaphoreMutex for a distributed locking recipe.


 


A typical path for a lock might be


 


/lock/calendar/<uuid>


 


I’d assume these paths need to be cleaned up eventually, so I’ve tried using childreaper
and reaper to do so after I unlock the lock.


 


ChildReaper kind of works. If I add /lock/calendar/uuid it happily removes the children. the
log shows it removes the leases and locks and the node itself is shown to be gone in zkClient
However suddenly it begins complaining in a seemingly endless loop that the path is gone.
This despite trying Mode.Delete and Mode.Until Gone.


 


Reaper does nothing, probably because /lock/calendar/uuid has children.


 


Am I missing something? Do I not need to clean up these locks? What do I need to worry concurrency
wise about.
Mime
View raw message