[
https://issues.jboss.org/browse/ISPN-2291?page=com.atlassian.jira.plugin....
]
Erik Salter commented on ISPN-2291:
-----------------------------------
Part of the issue is caused by the xsite.BaseBackupInterceptor and the fact that it
inherits BaseRpcManager, which has its own LockControlCommand impl. This causes the lock
command to be broadcasted to ALL members, not a subset. So on a rollback (and maybe even
commit), the command is only sent to a subset.
This can be mitigated by moving the base LockControlCommand handler to the derived
InvaidationInterceptors and ReplicationInterceptors.
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.Alpha3, 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