[
http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]
Jason T. Greene reopened JBCACHE-1165:
--------------------------------------
The fix introduced another endless loop problem:
Line 441:
else
{
// do the loop again, but don't assign child_node to currentNode so that
child_node is processed again.
if (System.currentTimeMillis() > expiryTime)
{
throw new TimeoutException("Unable to acquire lock on child node
" + new Fqn(currentNode.getFqn(), childName) + " after " + timeout + "
millis.");
}
}
Since currentNode is not set to the peeked node, this code will loop until a timeout
occurs, at which point an exception is always thrown.
Endless loop in PessimisticLockInterceptor, sometimes seen as a
NodeNotExistsException (when using READ_COMMITTED)
------------------------------------------------------------------------------------------------------------------
Key: JBCACHE-1165
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1165
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.0.0.GA, 1.4.1.SP4
Environment: Windows XP, Sun jdk150_06
Solaris 10
READ_COMMITTED
Reporter: Jacek Halat
Assigned To: Manik Surtani
Fix For: 2.1.0.GA, 2.1.0.CR2
Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
See ConcurrentPutRemoveTest
This sometimes manifests itself as an endless loop, and sometimes as a
NodeNotExistsException (on the putter thread) when concurrent puts and removes are
involved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira