[
https://issues.jboss.org/browse/ISPN-2483?page=com.atlassian.jira.plugin....
]
Dan Berindei updated ISPN-2483:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request:
https://github.com/infinispan/infinispan/pull/1621
Both scenarios could happen, because the state consumer could receive the topology update
before requesting transactions, and yet the provider may receive the same topology update
after sending the transactions.
The fix is to apply all transactions, without checking the originator, and then call
TransactionTable.updateStateOnNodesLeaving() again to catch transactions from any new
leavers.
State transfer issue with the transactions for which the originator
has crashed
-------------------------------------------------------------------------------
Key: ISPN-2483
URL:
https://issues.jboss.org/browse/ISPN-2483
Project: Infinispan
Issue Type: Bug
Components: State transfer, Transactions
Affects Versions: 5.1.8.Final, 5.2.0.Beta3
Reporter: Mircea Markus
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.Final
State transfer migrates and prepares the transactions for which the originator has left.
On the receiving node, this results in the transaction being prepared and acquiring backup
locks which are never released (unless manual intervention).
This should behave as follows:
- if there's no recovery enabled, the state producer should not send such
transactions but drop them
- if recovery is enabled these transactions should be sent across. They shouldn't be
prepared/acquire backup locks, but be placed in the recovery cache (see
RecoveryManagerImpl.inDoubtTransactions)
--
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