[
https://issues.jboss.org/browse/ISPN-2291?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-2291:
-------------------------------------
So my understanding of the problem is: a belated lock acquisition command (be it lock
acquisition or prepare) acquires some locks on keys that no longer map to this node. These
locks are never released. Is that correct?
Tx rollback during state transfer has stale locks
-------------------------------------------------
Key: ISPN-2291
URL:
https://issues.jboss.org/browse/ISPN-2291
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta1
Reporter: Erik Salter
Assignee: Adrian Nistor
Priority: Critical
Fix For: 5.2.0.CR1
There are stale locks that happened when a transaction failed due to a replication
timeout to its peer node. The transaction contained grouped keys that were submitted to
the primary owner. During execution of one such transaction, there was a state transfer,
which changed ownership of these keys.
Here's an example flow:
The task executed and started a transaction. Since it was not the primary owner, it sent
a LockControlCommand to the new owner. This call timed out, and a rollback was issued.
The local transaction is completed, but subsequent attempts to lock this key fail.
The logs can be found here:
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.83/server.log.gz
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.84/server.log.gz
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.85/server.log.gz
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira