Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
2.9.1
-
None
-
None
-
Windows 7
Java 1.7.0_60
ZooKeeper Server 3.4.6-1569965
Description
Issue: Downgrade pattern doesn't block already existed WRITE lock waiters.
Scenario:
- First thread takes a WRITE lock and waits
- Second thread starts and it is trying to obtain a WRITE lock. It waits because the WRITE lock is hold by the first thread.
- First thread does downgrade:
- Takes the READ lock
- Releases the WRITE lock
At this point the first thread still holds the READ lock but the second one will get the WRITE lock.
It is reproducible for:
- 2 threads use the same CuratorFramework instance
- 2 threads use the different sessions
- 2 separate JVMs
There is attached test class: DowngradeTest.java and zoo.cfg
Quote from Shared Reentrant Read Write Lock description
http://curator.apache.org/curator-recipes/shared-reentrant-read-write-lock.html
Lock Downgrading Re-entrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible.
Attachments
Attachments
Issue Links
- is superceded by
-
CURATOR-621 InterProcessReadWriteLock allows the write lock to be taken when the read one is not released
- Resolved