[infinispan-issues] [JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner
[
https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-3603:
-----------------------------------
Yes, there was a concurrent update which caused one replace to fail on the primary node.
The entry was changed by the ReplaceCommand.perform - after the entry got wrapped, the
command could be successfully execute on the node (the value was changed on primary node
between the remote get and replicating the replace command there) and so it got changed in
the command's context - and then it was committed.
Conditional command is committed on originator when it fails on
primary owner
-----------------------------------------------------------------------------
Key: ISPN-3603
URL: https://issues.jboss.org/browse/ISPN-3603
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.CR1
Reporter: Radim Vansa
Assignee: Pedro Ruivo
Priority: Critical
Labels: jdg62blocker
In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner
because the old value is not equal to current value, the
NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed
in EntryWrappingInterceptor anyway.
Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges:
NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the
primary owner, therefore, checking for command.isSuccessful() in order to retry the
command upon topology change may seem insufficient.
--
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