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

[Radim Vansa (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa reopened ISPN-3633:
-------------------------------



This issue still is not fixed for non-transactional cache: When topology changes so that owners [A, B] -> [A, C], C has the entry in L1 cache:

1. D executes PUT -> sends command to A
2. A executes the PUT, sends invalidation to C
3. ST from A to C begins
4. C receives InvalidateL1 and puts this key into updateKeys
5. C receives state but ignores the updated key

                
> 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
>              Labels: 620
>             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