[infinispan-issues] [JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache

[Radim Vansa (JIRA)]

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

Radim Vansa commented on ISPN-3617:
-----------------------------------

Right, after pointing me to the invalidation upon response to put from primary I've realized that the entry is about to be invalidated (and the log says so) but it is not committed as it is just wrapped for removal in the context - but the entry is not marked as removed.

Anyway, the {{EntryFactoryImpl.createWrappedEntry}} has {{forRemoval}} argument - why this is not honoured?
                
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
>                 Key: ISPN-3617
>                 URL: https://issues.jboss.org/browse/ISPN-3617
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Distributed Cache
>    Affects Versions: 5.2.7.Final
>            Reporter: Radim Vansa
>            Assignee: William Burns
>            Priority: Critical
>              Labels: jdg62blocker
>             Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.

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