]
Bela Ban commented on JGRP-1957:
--------------------------------
T means the member is a coordinator (true), F means it isn't (false).
S3_PING: Nodes never removed from .list file
--------------------------------------------
Key: JGRP-1957
URL:
https://issues.redhat.com/browse/JGRP-1957
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.4
Environment: JGroups client running on Mac OS X - Yosemite
JDK 1.7.71
Reporter: Nick Sawadsky
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.6
I'm not 100% sure, but it seems like there might be a defect here.
I'm using TCP, S3_PING, and MERGE3.
I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't
think the value of this setting affects my test results.
I start a single node, node A. Then I start a second node, node B.
I then repeatedly shutdown and restart node B.
Each time node B starts, a new row is added to the .list file stored in S3.
But even if I continue this process for 15 minutes, old rows are never removed from the
.list file, so it continues to grow in size.
I've read the docs and mailing list threads, so I'm aware that the list is not
immediately updated as soon as a member leaves. But I was expecting that when a view
change occurs, nodes no longer in the view would be marked for removal (line 2193 of
TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper
kicks in, once a new node joins, the expired cache entries would be purged from the file.
I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol
periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list
file, which includes expired nodes. And then all of these members are re-added to the
logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of
TP.java).
So expired nodes are continually re-added to the logical address cache, preventing them
from ever being reaped.