Bug 801734
| Summary: | Leaves last 1 min regradless of amount of data | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Michal Linhard <mlinhard> | ||||
| Component: | unspecified | Assignee: | Tristan Tarrant <ttarrant> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Nobody <nobody> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.0.0 | CC: | jdg-bugs, nobody | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 6.0.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-02-10 03:19:16 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Michal Linhard
2012-03-09 10:07:48 UTC
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. |
