[
https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin....
]
William Burns edited comment on ISPN-3617 at 10/21/13 1:08 PM:
---------------------------------------------------------------
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 the non owner L1
# 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.
was (Author: william.burns):
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