[GitHub] [accumulo] EdColeman commented on issue #1086: ZooLock uses ZooReader which may retry on session expired

[GitBox <gi...@apache.org>]

EdColeman commented on issue #1086:
URL: https://github.com/apache/accumulo/issues/1086#issuecomment-670197313


   Looking at the code and comparing that with the zookeeper examples on locks, would it be viable to use a guid when the ephemeral node is created?  (See https://zookeeper.apache.org/doc/r3.5.0-alpha/recipes.html#sc_recipes_errorHandlingNote - as well as the Recoverable Errors and the GUID section.)
   
   `When creating a sequential ephemeral node there is an error case in which the create() succeeds on the server but the server crashes before returning the name of the node to the client. When the client reconnects its session is still valid and, thus, the node is not removed. The implication is that it is difficult for the client to know if its node was created or not. `
   
   With this scheme, ZooLock may become independent of sessions - if the session that created the lock expires, then the ephemeral node goes away and without creating a new lock with a new guid there is no way to proceed.  This moves the issue from needing the session id to watching a particular node via a zk path that is unique for each time the lock is created / acquired.
   
   Another consideration may be that getting the session id is not thread safe. The getLockId() method is synchronized, but may not want to keep repeatedly asking for the session id.
   
   If this seems feasible, I could take a stab and see what it looks like.  Or, I just need to look more and then I would have found out why the is "a bad idea".


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org