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

--===============7704911682881587794==
Content-Type: multipart/alternative; boundary="0000000000004c657605e0cd25e3"

--0000000000004c657605e0cd25e3
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]>
> 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. 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?

- 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

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. 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

--0000000000004c657605e0cd25e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Although, looking at this again, I think =
we might not be talking about the same setup. From this:</div><br><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, May 26, 2021 at 3:26 AM Questions/problems related to using=
 JGroups via javagroups-users &lt;<a href=3D"mailto:javagroups-users@lists.=
sourceforge.net" target=3D"_blank">[email protected]</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[.=
...]<br>
<br>&gt; <br>
&gt; Right, and what they want is some way to fully remove a node from a <b=
r>
&gt; cluster. I.e. the cluster stops trying to contact that address.<br>
<br>
<br>
Then you would have to remove the 130 node from the old cluster&#39;s <br>
initial_hosts (TCPPING) and TCP&#39;s logical address cache. Either by <br>
restarting, or by programmatically removing it. This can get complex <br>
quickly though, as you&#39;d have to maintain a list of ports per cluster.<=
/blockquote></div></div></blockquote><div><br></div><div>Each cluster is se=
parate from all the others, so I don&#39;t know what I would need to keep i=
n this list or why a cluster would need it. If a cluster has A/B/C/D in it,=
 and the code sees that D leaves the cluster without going suspect first, c=
an I programmatically do these?</div><div><br></div><div>- set new initial_=
hosts on the existing TCPPING protocol in my stack to include only A/B/C</d=
iv><div>- access the logical address cache and remove the address</div><div=
><br></div><div>I mean, I know I can hack the TCPPING again, but didn&#39;t=
 know that would have any effect on the existing channel and members. I don=
&#39;t know offhand how to access the address cache, which I think is all I=
&#39;m missing to=C2=A0experiment with this. If I can do the above then I t=
hink that solves the issue -- if a suspect member leaves the view I won&#39=
;t do anything, because we want to keep trying it in case it was disconnect=
ed and reconnected. But if a member leaves gracefully and the above is all =
I need to make the cluster forget about it, that&#39;s great and means we w=
ouldn&#39;t have to change any startup features for the customers.</div><di=
v><br></div><div>Thanks again,<br></div><div>Bobby</div><div><br></div></di=
v></div>

--0000000000004c657605e0cd25e3--


--===============7704911682881587794==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7704911682881587794==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users

--===============7704911682881587794==--