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.
