InterprocessMutex Deadlock

[Kevinjeet Gill]

Hi,

I just wanted to confirm what I suspect is a bug. I've attached as minimal example as I could.

The problem I see is when InterprocessMutex.acquire() is called after receiving a Thread.interrupt().

The lock.acquire() will:

   A) Create a znode for the lock

   B) Throw an exception

   C) Return false when lock.isAcquiredInThisProcess() is called

This prevents anyone else from acquiring the lock since the znode can't be deleted via lock.release()

effectively causing a deadlock.

Thanks,

Kevinjeet

[Jordan Zimmerman]

Yes - that looks like a real bug. Please open an issue on github for this.

-JZ

--
You received this message because you are subscribed to the Google Groups "curator-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to curator-user...@googlegroups.com.
To post to this group, send email to curato...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/curator-users/-/KFIa8fk7ZcMJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
<MutexDeadlockEX.java>

[Jordan Zimmerman]

Actually, this looks like a bug in the ZooKeeper client. The node creation succeeds, but ZK's ClientCnxn.submitRequest() throws an exception when it calls wait() on the packet. Then again, why is the thread interrupted? Does every Curator call need to check Thread.isInterrupted first? I need to think more about this.

-JZ

On Mar 20, 2013, at 1:13 PM, Kevinjeet Gill <kevinj...@gmail.com> wrote:

[Kevinjeet Gill]

It shouldn't I think, but the lock around it should handle this within a catch(InterruptException) right? It shouldn't assume (in the case of an interrupt) that the znode was or wasn't created.