This is an issue we found lately in performance tests in JDG 6.0.0.ER2 https://docspace.corp.redhat.com/docs/DOC-94439 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: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experiments-mlinhard-perflab/65/ btw: It might be good to add JGroups as Component of "JBoss Enterprise Data Grid 6" product (and rename the product as well)
JGRP-1428 was probably meant instead of JGRP-1424.
Bela Ban <bela> 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 ?
Bela Ban <bela> 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
Bela Ban <bela> updated the status of jira JGRP-1428 to Resolved
Bela Ban <bela> made a comment on jira JGRP-1428 Feel free to re-open should the issue persist
I created ISPN-1904 to upgrade Infinispan to JGroups 3.0.7.
Created attachment 570542 [details] View installation times in ER4 elasticity test
http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/job/edg-60-elasticity-dist-basic/45/ In ER4 the state transfer no longer takes 1min.
Another confirmation of this is 4node elasticity test on hyperion: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-resilience-log-analysis/31/artifact/table.html http://www.qa.jboss.com/~mlinhard/hyperion/run27-elasticity4/report/stats-throughput.png
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.