Jordan, so, do you think it is feasible to do such changes into Curator locks? Via changes into LockInternalsDriver? If yes, should I go ahead and create a JIRA and draft a patch?
Best, Jozef On Wed, Jan 15, 2014 at 12:06 PM, Jozef Vilcek <[email protected]>wrote: > Yes. I was digging a bit in curator code and thinking about how can I > implement this. If I would be able to somehow intercept creation of lock > nodes, I could build GC/heartbeat logic around the lock by "installing" > appropriate hooks. > > One idea is that lock would accept a kind of LockNodeFactory, which would > be responsible for creating actual zookeeper nodes. > LockInternals.attemptLock() would delegate construction to the factory. > There, in my own factory, I could add posibility to listen to created lock > nodes and apply GC/heartbeat logic. > > As you suggested, same could be done if node creation would be moved to > the LockInternalsDriver and made public/reusable. I like this even better. > It could be tricky how to reuse e.g. read-write lock, but it would not be > so painful to "re-implement" only that part of curator code on my end. > > > Jozo > > > On Tue, Jan 14, 2014 at 6:51 PM, Jordan Zimmerman < > [email protected]> wrote: > >> You might be able to re-use the code in the LockInternals class. It could >> easily be modified to do what you want via the LockInternalsDriver. Of >> course it would need to be made public. The gc/heartbeat stuff would have >> to be coded fresh, though. >> >> -Jordan >> >> ------------------------------ >> From: Jozef Vilcek Jozef Vilcek <[email protected]> >> Reply: Jozef Vilcek [email protected] >> Date: January 14, 2014 at 12:18:15 AM >> To: Jordan Zimmerman [email protected] >> Subject: Re: Persistent locks >> >> Yes, you are correct. I tried to sketch this in my post. There will be >> possibility to create persistent lock, which will cause deadlock if holder >> crashes and one with possibility to to be gc collected after some time if >> holder crashes. The mechanism for this has to be implemented. >> >> Off course that I use "classical" ephemeral locks where possible. But I >> have few cases where it is not feasible. >> >> >> On Tue, Jan 14, 2014 at 2:42 AM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> How will you avoid dead locks? You’ll need to write some kind of >>> heartbeat/gc mechanism to the lock. Otherwise I don’t see how it works if >>> the lock holder crashes. >>> >>> -JZ >>> >>> ------------------------------ >>> From: Jozef Vilcek Jozef Vilcek <[email protected]> >>> Reply: [email protected] [email protected] >>> Date: January 13, 2014 at 7:24:06 AM >>> To: [email protected] [email protected] >>> Subject: Persistent locks >>> >>> Hi >>> >>> I have a question about curator locks. I see that locks are implemented >>> via znode type EPHEMERAL_SEQUENTIAL. I am thinking about having an >>> implementation via PERSISTENT_SEQUENTIAL. >>> >>> Main reason for this are processes with critical sections, where we can >>> not afford to loose a lock due to session expiration. In such case, others >>> might acquire a lock and kick in while the previous process is still >>> running but e.g. experiencing connection issues. To kill this temporally >>> detached process in favor of others would be too costly. >>> >>> My thoughts are to have: >>> >>> * Persistent lock - if something go south and client code does not >>> release lock, it will stay there until removed by manual or some other >>> intervention >>> >>> * Persistent ephemeral lock - this would be ephemeral implemented by >>> persistent lock. For not so much critical stuff but e.g. for unstable >>> environments. This would install kind of refresh hook on a created lock >>> node. Other clients waiting to acquire lock could garbage collect locks >>> which does not received refresh for reasonable long time (scaling beyond >>> session timeouts). >>> >>> What I would like to know: >>> >>> * any wisdom, if this does make sense or if there is a better way out >>> there >>> * support from curator ... There is a lot of good code in curator I >>> would have to copy to make this work. I want to avoid this. Would it be >>> possible of provide either path for making locks core extensible/reusable >>> (or to contribute implementation of locks if considered worth for >>> framework) ? >>> >>> >>> Best, >>> Jozo >>> >>> >> >
