curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-401) Make InterProcessMutex.isOwnedByCurrentThread public
Date Tue, 25 Apr 2017 02:51:04 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982306#comment-15982306
] 

ASF GitHub Bot commented on CURATOR-401:
----------------------------------------

Github user asfgit closed the pull request at:

    https://github.com/apache/curator/pull/214


> Make InterProcessMutex.isOwnedByCurrentThread public
> ----------------------------------------------------
>
>                 Key: CURATOR-401
>                 URL: https://issues.apache.org/jira/browse/CURATOR-401
>             Project: Apache Curator
>          Issue Type: Improvement
>          Components: Recipes
>    Affects Versions: 2.12.0
>            Reporter: Stig Rohde Døssing
>            Priority: Minor
>
> It is useful in some cases to be able to tell if the current thread holds the lock before
calling acquire. I have some components using InterProcessMutex for coordination that are
intended to run in different JVMs in production. I'd like to be able to write an integration
test that runs them in the same JVM in different threads, and verify that the lock is held
by the expected component at certain points in the code.
> Using InterProcessMutex.isAcquiredInThisProcess is not a good replacement in this case,
and acquiring/releasing the lock unnecessarily also doesn't seem like a good solution.
> InterProcessMutex already supports this functionality, but the method is package private.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message