[
https://issues.jboss.org/browse/JGRP-1428?page=com.atlassian.jira.plugin....
]
Bela Ban commented on 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
UnicastRequest and GroupRequest should mark a target as suspected if
the target has already left the cluster at creation time
-----------------------------------------------------------------------------------------------------------------------------
Key: JGRP-1428
URL:
https://issues.jboss.org/browse/JGRP-1428
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.5, 3.1
Reporter: Dan Berindei
Assignee: Bela Ban
Priority: Critical
Fix For: 3.0.7, 3.1
UnicastRequest and GroupsRequest both detect if a target has left the cluster and mark
its response as "suspected".
However, if the node has already left the cluster by the time the request is created, its
response is not marked as "suspected" and the request never properly finishes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira