[
https://jira.jboss.org/jira/browse/JBCACHE-1549?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1549:
-------------------------------------------
The testsuite ran OK with that block commented it out (had 3 failures but seemed
unrelated). So I committed that; I'll let hudson have a go at it and if it looks ok
will assign this to myself and resolve it.
Buddy pool tracking when 2nd to last member leaves group
--------------------------------------------------------
Key: JBCACHE-1549
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1549
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Buddy Replication
Affects Versions: 3.2.1.GA
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Critical
If you have a 2 node cluster with buddy replication, and you restart one node, that node
does not receive a state transfer. See forum thread for details of the exact symptoms.
Problem is this in BuddyManager$AsyncViewHandlerThread.handleEnqueuedViewChange():
// there is a strange case where JGroups issues view changes and just includes
self in new views, and then
// quickly corrects it. Happens intermittently on some unit tests. If this is
such a case, please ignore.
if (members.newMembers.size() == 1 &&
members.newMembers.get(0).equals(cache.getLocalAddress()))
{
log.info("Ignoring membership change event since it only contains
self.");
return;
}
Problem is the if condition is always true when the 2nd to last member leaves the group,
but returning leaves the last member in a state where it thinks the next to last member is
still a buddy. When that node restarts and rejoins the group, the reassign buddies logic
sees that the new member is already a buddy and returns without pushing state.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira