[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:comment-tabpanel&focusedCommentId=12823584#comment-12823584 ] 

Radim Vansa commented on ISPN-3633:
-----------------------------------

This was a transactional cache, with default (read committed) isolation.

Here is an excerpt from the logs, the full ones are on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-radargun-resilience-dist-tx-l1/1/artifact/report/stdout.zip
08:38:28,313 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-21) Key key_000000000000491A modified by a regular tx, state transfer will ignore it
08:38:28,313 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-21) Entry for key key_000000000000491A is null : not calling commitUpdate

Then later on, when executing StateResponseCommand:

08:38:45,514 TRACE [org.infinispan.transaction.LocalTransaction] (remote-thread-20) Adding modification PutKeyValueCommand{key=key_000000000000491A, value=[37 #1: 173, ], flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}. Mod list is null
08:38:45,526 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-20) State transfer will not write key/value key_000000000000491A/[37 #1: 173, ] because it was already updated by somebody else

Therefore, for reproduction of this bug you need to get to this situation
1. A gets entry from B, caches that
2. state transfer from B to A begins (B is previous owner, A is new one) - some delay or many entries would be required here
3. entry is overwritten on B, invalidating A's record
4. when A get's the StateResponseCommand, the entry is not set
5. you may check the entry on A to be still null

Is there anything that should prohibit this behaviour? Am I oversimplifying something?



                
> 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