Re: [jgroups-users] removing unknown address from cluster? JGRP000032

[Questions/problems r. to u. J. <jav...@li...>]

On 06.06.22 22:15, Questions/problems related to using JGroups wrote:
> Although, looking at this again, I think we might not be talking about 
> the same setup. From this:
> 
> 
> 
>     On Wed, May 26, 2021 at 3:26 AM Questions/problems related to using
>     JGroups via javagroups-users <jav...@li...
>     <mailto:jav...@li...>> wrote:
> 
>         [....]
> 
>          >
>          > Right, and what they want is some way to fully remove a node
>         from a
>          > cluster. I.e. the cluster stops trying to contact that address.
> 
> 
>         Then you would have to remove the 130 node from the old cluster's
>         initial_hosts (TCPPING) and TCP's logical address cache. Either by
>         restarting, or by programmatically removing it. This can get
>         complex
>         quickly though, as you'd have to maintain a list of ports per
>         cluster.
> 
> 
> Each cluster is separate from all the others, so I don't know what I 
> would need to keep in this list or why a cluster would need it. 


Referring to my previous email: if you use FILE_PING, each cluster has a 
_separate_ directory (the cluster name) under which the discovery info 
is stored.


> If a cluster has A/B/C/D in it, and the code sees that D leaves the cluster 
> without going suspect first, can I programmatically do these?

For TCP, it's complicated, but doable. Among other things you'd have to:
- Close all TCP connections to D
- Close all connections to D in UNICAST3, too
- Remove D's info from the address cache (contents: 'probe.sh uuids')
- Remove D's information from all instances of TCPPING (initial_hosts 
and dynamic_hosts)

Again, using a dynamic discovery protocol such as FILE_PING makes more 
sense here.

> - set new initial_hosts on the existing TCPPING protocol in my stack to 
> include only A/B/C
> - access the logical address cache and remove the address

Yes, but this is not enough (see above).

> I mean, I know I can hack the TCPPING again, but didn't know that would 
> have any effect on the existing channel and members. I don't know 
> offhand how to access the address cache, which I think is all I'm 
> missing to experiment with this.

Pseudo code:
TP tp=channel.getProtocolStack().getTransport();
LazyRemovalCache cache=tp.getLogicalAddressCache();
cache.remove(address, true); // force removal


> If I can do the above then I think that 
> solves the issue -- if a suspect member leaves the view I won't do 
> anything, because we want to keep trying it in case it was disconnected 
> and reconnected. But if a member leaves gracefully and the above is all 
> I need to make the cluster forget about it, that's great and means we 
> wouldn't have to change any startup features for the customers.
> 
> Thanks again,
> Bobby
> 
> 
> 
> _______________________________________________
> javagroups-users mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users

-- 
Bela Ban | http://www.jgroups.org