-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InterProcessMutex from multiple threads #31
Comments
It's not correct that the JVM ReentrantLock allows multi-threaded usage. It wouldn't be very useful if it did. Maybe I'm misunderstanding your use case. Here's an example I wrote with ReentrantLock.
|
Thanks for replying. The point I wanted to get across was that I felt that the acquire method should block within the same jvm like it does across jvms. If inter process mutex is called from 2 different threads at the same time in the same jvm right now, the first one will get access and the second call will result in an illegal monitor exception (rather than blocking). I work around this with a simple java lock in my trait that wraps the mutex, just thought it would be nice if this was kept within the library. |
OK - I understand now. I consider this a bug and I'll work on a fix. As a workaround, you can allocate a new InterProcessMutex in each thread. |
I wonder if it is not better to leverage Google Collections' Function class and put the acquire and release methods together. Adding synchronized to my lock method works fine for now: (scala) trait Lockable extends ZooKeeperHarness { val nodePathToLockUpon: String private[cluster] lazy val lock: InterProcessLock = { def lock(functionToExecuteWhileLocked: => Unit) { The InterProcessMutex per thread solution would work as well; these locks are used infrequently so I am not really concerned about the contention. |
I've pushed a fix - I'll build new binaries when I can. Thanks for finding this. |
@Randgalt Could you show me the push url? Thanks. |
Sorry @r7raul1984 - I don't know what you mean. Also, Curator is now at Apache. See https://curator.apache.org |
@Randgalt About InterProcessMutex ,I wanted to get across was that I felt that the acquire method should block within the same jvm like it does across jvms. How to fix it? Which version of Curator support this ? |
|
@Randgalt OK. Thank you! I should create new CuratorFramework client for every InterProcessMutex. Many InterProcessMutex instance can't share one CuratorFramework client. Is that correct? |
No - 1 CuratorFramework instance is enough for your entire application. |
@Randgalt Thanks. |
I started testing with the InterProcessMutex today and was surprised to find out that it threw an IllegalMonitorException if another thread in the same jvm already had the lock. What I expected was behaviour within the same jvm similar to Java's standard ReentrantLock.
What are the best practices for the case where one would like the lock to be shared both within and across jvms? What I can do short term is to try/catch the illegal monitor exception everywhere I need to call the lock but that seems cludgy and is less than ideal. It seems like to get the behaviour I would really want the acquire method would need the ability to block.
The text was updated successfully, but these errors were encountered: