[jira] [Work logged] (CURATOR-592) Provide a callback that is fired after the InterProcessMutex creates its ephemeral node

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CURATOR-592?focusedWorklogId=610445&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610445 ]

ASF GitHub Bot logged work on CURATOR-592:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 14/Jun/21 07:52
            Start Date: 14/Jun/21 07:52
    Worklog Time Spent: 10m 
      Work Description: Randgalt edited a comment on pull request #384:
URL: https://github.com/apache/curator/pull/384#issuecomment-860149800


   While I understand why this might be useful for you I'm concerned about adding such a bespoke feature to Curator. The lock code is already complicated and introducing this shim makes it much harder to reason about. We can't predict what this proc will do in the context of the lock mechanics. I'm sorry but I'm -1 on this change. But maybe one of the other committers will accept it.


-- 
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


Issue Time Tracking
-------------------

    Worklog Id:     (was: 610445)
    Time Spent: 0.5h  (was: 20m)

> Provide a callback that is fired after the InterProcessMutex creates its ephemeral node
> ---------------------------------------------------------------------------------------
>
>                 Key: CURATOR-592
>                 URL: https://issues.apache.org/jira/browse/CURATOR-592
>             Project: Apache Curator
>          Issue Type: Improvement
>          Components: Recipes
>    Affects Versions: 5.1.0
>            Reporter: Mohamed Mohsen
>            Priority: Major
>              Labels: Concurrency
>             Fix For: TBD
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{InterProcessMutex}} performs two significant steps to [acquire|https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessMutex.html#acquire()] its lock:
>  # Creates an ephemeral sequential node. This practically means that it took a position in the lock queue (i.e. based on its sequence value).
>  # Blocks until the lock is acquired.
> This improvement is about providing a callback that notifies the caller that the lock order is reserved.
> The use for this, at least for us, is that we needed to differentiate between the two phases for higher concurrency because we can do other actions after knowing that the {{InterProcessMutex}} order is known. Especially since the lock acquisition can take too long, depending on the situation of course.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)