curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miller, Austin" <Austin.Mil...@morganstanley.com>
Subject Watching Mutex/Semaphore/LeaderSelector for acquisitions
Date Mon, 02 Jun 2014 14:29:47 GMT
Hi,

My general goal is to be able to get the "id" of who has locked an InterProcessMutex, who
has leases from an InterProcessSemaphoreV2, or who is elected leader in LeaderSelector from
a process/jvm that is not trying to acquire the locks or to be a leader.   Not only that,
I would like to "watch" changes.  There does not seem to be a good way to do this without
violating the encapsulation of all three classes.

I will treat just the semaphore case in detail as it is of the most interest to me, at the
moment.

My current understanding with InterProcessSemaphoreV2#getParticipatingNodes is that it returns
N + 1 leases where N == maxLeases.  The +1 is the lease that will happen when any of N is
returned.   Let path be the string argument supplied to the constructor called path, if I
set a watch on path + "/leases", take the resulting children, order them lexicographically
by the remainder of the path following the substring "-leases-", and return the first N children...
I should have all the nodes who have leases from the semaphore.

This is also understanding that the child nodes can change between the call to get the child
nodes and the call to get the data for the children in order to determine an id.  However,
if the data is acquired for M nodes in first N nodes, it can be safely assumed that the nodes
in M have acquired a lease or only very recently lost it/are losing it.  I'm also thinking
that the portion after -lease- is always incremented such that the incremented number won't
be seen again once used.  I also want to assume that if K is the (N+1)th node, and getData
does not return for a node in the first N because it doesn't exist (that is, M is a proper
subset of N), then K, if getData returns, is now a lease holder.

My concern with this is that it completely skips the class encapsulation and relies on the
class not changing how it implements the underlying lock in ZK in order to continue to work
through upgrades.  I'm also not totally certain I got the logic right.  Moreover, my way of
acquiring the information and my implementation is not battle-tested and not seen by the larger
curator community for community improvement/comment.

Would it be wise to add something like "public static void watch(CuratorFramework,String path,AcquisitionListener
cw,...)" to each of these classes to achieve this behavior inside the library in a way that
is consistent with the implementation of each recipe?  I know it is an additional contract
to support, but I think it would add value.

Austin


________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained
herein are not intended to be, and do not constitute, advice within the meaning of Section
975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received
this communication in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality or privilege.
Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor
electronic communications. This message is subject to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us
by reply message and we will send the contents to you. By messaging with Morgan Stanley you
consent to the foregoing.

Mime
View raw message