[infinispan-issues] [JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
William Burns (JIRA)
jira-events at lists.jboss.org
Mon Oct 21 13:07:02 EDT 2013
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823691#comment-12823691 ]
William Burns commented on ISPN-3617:
-------------------------------------
Actually I think this is related to ISPN-3273. I have a guess as to what you may have seen.
My guess is that this operation happened:
# put ran on primary owner
# primary owner replicates to backup owner (not yet committed on primary) - backup owner invalidated on non owner
# get from non owner retrieves the old value from owner
# primary owner completes but doesn't invalidate the non owner since it was the one who updated
I will have to write up a test, but I am pretty sure this is what you saw.
> 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
More information about the infinispan-issues
mailing list