• Bug
  • Status: Closed
  • 1 Critical
  • Resolution: Fixed
  • cdennis
  • Reporter: cdennis
  • August 04, 2009
  • 0
  • Watchers: 0
  • August 20, 2009
  • August 05, 2009


Currently the code in ClientLock allows a held concurrent write lock to prevent a recall from occurring. In addition when the concurrent write lock is unlocked the lock is still not recalled to the server. This can cause the cluster to stall with nodes waiting indefinitiely for the recall of a lock that will never happen.

I have implemented a fix for this that stops concurrent write locks from preventing a greedy recall. The greedy lock is not required to establish the concurrent write lock hold and so should not be required for the hold to continue.

Entry timestamps in the distributed cache implementation are updated using concurrent write locks, and this is where the bug was first seen.


Chris Dennis 2009-08-05

This was caused by a bug in the ClientLock whereby a held concurrent write lock could both block a recall while it was being held, but also refused to trigger a recall when it was unlocked and the lock became free for recalling. With these changes concurrent write holds no longer block a recall from occurring.

Kalai Kannaiyan 2009-08-13

Verified the fix merged to 3.1 with svn rev13338 and system test added.