[infinispan-issues] [JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812306#comment-12812306 ] 

Dan Berindei commented on ISPN-3603:
------------------------------------

I think the problem is that {{EntryWrappingInterceptor}} doesn't wrap the entry on the originator, but then {{NonTxDistributionInterceptor}} retrieves the key from another owner and wraps the entry itself (because state transfer is in progress and the originator is in the process of receiving the entry via state transfer).

In fact, I think {{NonTxDistributionInterceptor.remoteGetBeforeWrite()}} is not needed at all. The remote get was required in order to check the previous value (or return it, for non-conditional commands). But in non-tx caches, only the return value on the primary owner matters, and the primary owner always has the value. So it should be safe to remove {{remoteGetBeforeWrite()}} completely.
                
> 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: Mircea Markus
>            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