[infinispan-issues] [JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

[William Burns (JIRA)]

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

William Burns commented on ISPN-3633:
-------------------------------------

I was finally able to reproduce the problem.

It has to be done as so.

A - primary owner
C - non owner

# C gets value for k from A the current value and caches it in L1
# A is updating k with a new value in an explicit tx along with another entry that maps to C
# A sends and completes prepare to C where it believes it is only updating the other entry (note commit is not yet sent)
# State transfer starts and now C is the owner of k (note data has not been transferred yet)
# A now commits the tx which causes an invalidation to be sent to C and the value to be marked as modified
# State transfer finally is sent to C for data and is ignored.

Actually thinking about this it may have a worse issue even when L1 is not enabled that the data cached is the old value as it wouldn't retrieve the value from the put command.  I would need to test that still though.
                
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
>                 Key: ISPN-3633
>                 URL: https://issues.jboss.org/browse/ISPN-3633
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Distributed Cache
>    Affects Versions: 5.3.0.Final
>            Reporter: Radim Vansa
>            Assignee: William Burns
>            Priority: Critical
>             Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.

--
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