Bug 1163665 – Node can temporarily read removed data when another node joins the cluster, leaves or crashes

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 1163665 - Node can temporarily read removed data when another node joins the cluster, leaves or crashes

Summary:	Node can temporarily read removed data when another node joins the cluster, l...

Status:	ASSIGNED

Aliases:	None

Product:	JBoss Data Grid 6
Classification:	JBoss
Component:	Infinispan (Show other bugs)
Sub Component:
Version:	6.4.0
Hardware:	Unspecified Unspecified

Priority	unspecified Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Pedro Ruivo
QA Contact:	Martin Gencur
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2014-11-13 04:10 EST by Radim Vansa
Modified:	2018-01-29 20:45 EST (History)
CC List:	7 users (show)

See Also:
Fixed In Version:
Doc Type:	Known Issue
Doc Text:	In Red Hat JBoss Data Grid, the distribution of entries in the cluster changes when a node joins, leaves or crashes. During this brief period, a read on the previous node owner can return stale data. When the rebalance process is completed, further reads return up-to-date data. This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.
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)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
JBoss Issue Tracker	ISPN-4444	Critical	Resolved	After state transfer, a node is able to read keys it no longer owns from its data container	2018-02-28 17:34 EST
JBoss Issue Tracker	ISPN-5021	Critical	Resolved	Nodes that finish the rebalance later can see outdated values	2018-02-28 17:34 EST

Groups: None (edit)

Description Radim Vansa 2014-11-13 04:10:15 EST

Comment 2 JBoss JIRA Server 2014-11-17 09:44:48 EST

Pedro Ruivo <pruivo@redhat.com> updated the status of jira ISPN-4444 to Coding In Progress

Comment 3 JBoss JIRA Server 2014-11-26 05:13:31 EST

Dan Berindei <dberinde@redhat.com> updated the status of jira ISPN-4444 to Reopened

Comment 6 JBoss JIRA Server 2014-12-17 11:45:04 EST

Pedro Ruivo <pruivo@redhat.com> updated the status of jira ISPN-5021 to Coding In Progress

Comment 7 Tristan Tarrant 2014-12-23 04:00:26 EST

I think we should split this bug in two and mark this issue as resolved

Comment 8 Pedro Ruivo 2015-01-05 06:17:43 EST

this is a tricky one. I'm currently work on it but I think the solution I have in mind will solve it.

Comment 9 Radim Vansa 2015-01-05 11:21:22 EST

The stale value can be read only for a brief period of time.

Since we want rather *eventual* consistency than guarantee up-to-date reads in crash/join/leave/split-brain scenarios, this issue is not critical to JDG.

Comment 11 Radim Vansa 2015-01-07 03:35:47 EST

Any resilience tests had trouble with https://bugzilla.redhat.com/show_bug.cgi?id=1166243 . I need to test this yet further, but it seems that partition handling is behaving as expected, since the cache is allowed to become inconsistent/provide stale data in certain time window.

Comment 13 Radim Vansa 2015-01-09 03:33:31 EST

This BZ is related to reading stale data, not inconsistent result of writes. What BZ would you like me to verify?

Described test setup is possible.

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