Bug 801734 - Leaves last 1 min regradless of amount of data
Leaves last 1 min regradless of amount of data
Product: JBoss Data Grid 6
Classification: JBoss
Component: unspecified (Show other bugs)
Unspecified Unspecified
medium Severity high
: ---
: 6.0.0
Assigned To: Tristan Tarrant
nobody nobody
Depends On:
  Show dependency treegraph
Reported: 2012-03-09 05:07 EST by Michal Linhard
Modified: 2014-03-17 00:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
View installation times in ER4 elasticity test (1.25 KB, text/html)
2012-03-16 05:11 EDT, Michal Linhard
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JGRP-1428 None Resolved UnicastRequest and GroupRequest should mark a target as suspected if the target has already left the cluster at creation... 2012-03-16 07:57:14 EDT

  None (edit)
Description Michal Linhard 2012-03-09 05:07:48 EST
This is an issue we found lately in performance tests in JDG 6.0.0.ER2

We've been working on this with Dan and last result is that Dan reopened JGRP-1424 as he suspects it not being fixed completely.

This is just for the record so that it's not forgotten.

TRACE log of JGroups and Infinispan in the problematic elasticity test:

btw: It might be good to add JGroups as Component of "JBoss Enterprise Data Grid 6" product (and rename the product as well)
Comment 1 Michal Linhard 2012-03-09 05:31:04 EST
JGRP-1428 was probably meant instead of JGRP-1424.
Comment 2 JBoss JIRA Server 2012-03-09 07:22:18 EST
Bela Ban <bela@jboss.com> made a comment on jira JGRP-1428

After the request is created, even if it misses the new view installed at the same time the request is added, it will get called viewChange(), so its membership should be correct. After this, view change notifications will be handled the normal way.

Can you show me a timing scenario which causes a request to have an incorrect target set ?
Comment 3 JBoss JIRA Server 2012-03-12 08:26:58 EDT
Bela Ban <bela@jboss.com> made a comment on jira JGRP-1428

Here's a scenario which could still reproduce the bug:
- The current view is is V1
- RequestCorrelator.receiveView() installs a new view V2 and starts iterating over requests
- A new Request is added to 'requests'. Because the iterator above iterates on a ConcurrentHashmap, it will iterate over a copy and *not* call viewChange(V2) on the request !
- RequestCorrelator.send(Unicast)Request() now calls viewChange(V1) on the request. V1 is used because the assignment of V2 to RequestCorrelator.view has *not* yet happened !
- RequestCorrelator.receiveView() now assigns V2 to this.view

--> In this scenario, we do *not* call viewChange(V2) on the request, but only use the old view V1 !
==> Moving the assignment of V2 to this.view *before* the iteration should fix the issue
Comment 4 JBoss JIRA Server 2012-03-12 08:28:12 EDT
Bela Ban <bela@jboss.com> updated the status of jira JGRP-1428 to Resolved
Comment 5 JBoss JIRA Server 2012-03-12 08:28:12 EDT
Bela Ban <bela@jboss.com> made a comment on jira JGRP-1428

Feel free to re-open should the issue persist
Comment 6 Dan Berindei 2012-03-12 08:38:48 EDT
I created ISPN-1904 to upgrade Infinispan to JGroups 3.0.7.
Comment 7 Michal Linhard 2012-03-16 05:11:41 EDT
Created attachment 570542 [details]
View installation times in ER4 elasticity test
Comment 8 Michal Linhard 2012-03-16 05:12:53 EDT

In ER4 the state transfer no longer takes 1min.

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