Bug 1021362 - Inconsistent L1 in tx distributed cache
Inconsistent L1 in tx distributed cache
Status: VERIFIED
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity high
: ER4
: 6.2.0
Assigned To: Tristan Tarrant
Martin Gencur
:
: 1024937 (view as bug list)
Depends On:
Blocks: 1017190
  Show dependency treegraph
 
Reported: 2013-10-21 03:27 EDT by Radim Vansa
Modified: 2014-03-24 21:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
With L1 enabled, a node may cache an already overwritten entry. Further reads on this node will return out-of-date value.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ISPN-3648 Critical Resolved Inconsistent L1 in tx distributed cache 2014-05-23 02:57:22 EDT

  None (edit)
Description Radim Vansa 2013-10-21 03:27:06 EDT
In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes.
Comment 1 Radim Vansa 2013-10-21 03:28:08 EDT
This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1017796
Comment 3 JBoss JIRA Server 2013-10-21 17:47:08 EDT
William Burns <wburns@redhat.com> updated the status of jira ISPN-3648 to Coding In Progress
Comment 4 JBoss JIRA Server 2013-10-21 18:33:59 EDT
William Burns <wburns@redhat.com> made a comment on jira ISPN-3648

So if I understand correctly what you are saying is more that the issue is that the non owner requests a get but only the backup owner answers and the get doesn't reach the primary until after the update occurs causing it to cache an invalid value.

I am thinking this may be due to the fact that the tx l1 code only did invalidates if the context is local, which sounds like to be more consistent we have to do it on a Commit command even if it isn't local.

I will try to make up a test case of both an implicit tx and a explicit tx that is started not on an owner node.
Comment 5 JBoss JIRA Server 2013-10-21 18:43:34 EDT
William Burns <wburns@redhat.com> made a comment on jira ISPN-3648

It sounds like the issue is that the non owner requests a get but only the backup owner answers and the get doesn't reach the primary until after the update occurs causing it to cache an invalid value.

I am thinking this may be due to the fact that the tx l1 code only did invalidates if the context is local, which sounds like to be more consistent we have to do it on a Commit command even if it isn't local.

I will try to make up a test case of both an implicit tx and a explicit tx that is started not on an owner node.
Comment 6 JBoss JIRA Server 2013-10-21 20:06:55 EDT
William Burns <wburns@redhat.com> made a comment on jira ISPN-3648

I can reproduce the issue, however L1 in TX mode has always been invalidated by the owner node, which in this case just won't work.  I will need to think over what I can do for this.  I am guessing we only want to do this invalidation inside the LastChance and leave the normal L1Interceptor alone.
Comment 7 JBoss JIRA Server 2013-10-22 12:53:13 EDT
William Burns <wburns@redhat.com> made a comment on jira ISPN-3648

Actually this is also an exact match for ISPN-3426
Comment 8 Radim Vansa 2013-12-10 05:12:48 EST
*** Bug 1024937 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.