[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Erik Salter updated ISPN-1343: ------------------------------ Attachment: RehashTest.java Updated unit test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Changgeng Li commented on ISPN-1343: ------------------------------------ Another issue is found during the test. See ISPN-1344. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1343: ------------------------------------ The retry queue processor was not properly waiting for the cache to start up, so it could start handling a command before the initial rehash. That command would in turn block the rehash from starting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-1343: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/519 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-1343: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.0.1.FINAL Resolution: Done Fixed the issue of distributed tasks starting before the node is up with ISPN-1365. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Erik Salter updated ISPN-1343: ------------------------------ Attachment: ISPN-5-stale-lock.zip -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1343: ------------------------------------ Ok, I think I found the problem. When a PrepareCommand fails (in our case because it didn't get a reply from the remote node in 15 seconds), LockingInterceptor catches the exception and releases all the locks acquired by the transaction. After that TransactionCoordinator starts a proper rollback, but the entries in the invocation context are no longer locked (and in 5.0 that means they only have the VALID flag set, not CHANGED or CREATED). That means local locks are not released twice, but it also means the PrepareCommand is not executed remotely (BaseRpcInterceptor.shouldInvokeRemoteTxCommand() returns false). I see 3 possible solutions: 1. Don't clean up the locks at all in LockingInterceptor (if the invocation context is transactional) and rely on TransactionCoordinator to do it. 2. Clean up the locks but don't call rollback() on the entry. 3. Rely on LocalTransaction's getRemoteLocksAcquired() instead of the locked entries to determine if the rollback command should be executed on the remote nodes. I've only looked at this on 5.0, I'll get Mircea to take a look at the issue for 5.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1343?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1343: ------------------------------------ The stale locks are still appearing with 5.1, I've discussed it with Mircea and we've decided to choose the 1st option. Erik has since found another scenario with stale locks after a commit command fails, so I have created separate subtasks for each of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira