Re: [jgroups-users] removing unknown address from cluster? JGRP000032
Questions/problems related to using JGroups <[email protected]> Mon, 6 Jun 2022 15:08:35 -0400
| Newsgroups | gmane.comp.java.javagroups.general |
|---|---|
| Message-ID | <mailman.5237.1654544119.1462.javagroups-users@lists.sourceforge.net> |
--===============2536819582008943884== Content-Type: multipart/alternative; boundary="0000000000000f429905e0cc35e4" --0000000000000f429905e0cc35e4 Content-Type: text/plain; charset="UTF-8" Hi again Bela et al, We've finally come back to this issue after not working on the product for a while. I'm keeping the context all below, but the short version was that we use TCPPING and, if someone removes a node with address X and, later, starts a new cluster that includes the address, the old cluster keeps trying to find its lost buddy at X. We're still back on v4.1.8 and I wanted to ask if the suggestion below, i.e. use TCPGOSSIP or FILE_PING (this is for in-house deployments on their own networks) is the most appropriate, and if there would be any benefit for this particular issue by moving to v5.X? The way they run things now is to put host:port info for each node in a file and then start the applications, which read that file to set initial hosts. So FILE_PING might be the best for them so that we don't need to have any new processes running. Thanks, Bobby On Wed, May 26, 2021 at 3:26 AM Questions/problems related to using JGroups via javagroups-users <[email protected]> wrote: > > > On 25.05.21 18:59, Questions/problems related to using JGroups wrote: > > On Tue, May 25, 2021 at 10:30 AM Questions/problems related to using > > JGroups via javagroups-users <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Bobby > > apologies for the delay! > > > > > > No problem -- thanks for looking. > > > > > > You cannot have the old cluster's initial_hosts be 128,129,130 and > the > > new one has the overlapping range 130,131. > > > > > > That's the problem. The customer has lots of nodes, clusters that grow > > and shrink, and they're going to reuse the same IP addresses eventually. > > > Then using TCPPING for the discovery is the wrong solution; it is > designed for a static cluster with a fixed and known membership. > > For the above requirements, I'd rather recommend: > * A dynamic discovery mechanism (TCPGOSSIP, FILE_PING, GOOGLE_PING etc) > * Emphemeral ports > * A new (different) cluster name for each new cluster that is started > > > > The old cluster will try to contact 130 (e.g. trying to merge), > thereby > > send its information to 130. > > > > > > 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. > > The first solution above is much better IMO. > > > > What is it you're trying to achieve? > > > > > > Simply to take a node out of a cluster when it's not needed, then later > > reuse the address of that node with a different cluster. If I change the > > cluster names (same port though) then I still get constant warnings, > like: > > JGRP000012: discarded message from different cluster <old> (our cluster > > is <new>). Sender was <some addr> > > > > We can suggest that they restart the cluster after removing a node, but > > I don't know if that will work for them. I'll also try using different > > ports for different clusters and see how that works for them. > > That will certainly work, but - again - you'd have to maintain ports > numbers for each cluster. Registration service? Excel spreadsheet? > > > > Given the size of the company in question, I can see that it might be > hard to > > coordinate that and eventually they'll get back in the same situation > > where a previously used address is being used again with the same port > > it used the last time. > > Right. So I have to come back to my suggestion of not using TCPPING! > Cheers, > > > > Thanks, > > Bobby > > > > > > > > _______________________________________________ > > javagroups-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/javagroups-users > > > > -- > Bela Ban | http://www.jgroups.org > > > > _______________________________________________ > javagroups-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/javagroups-users > --0000000000000f429905e0cc35e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Hi again Bela et al,<div><br></div><div>W= e've finally come back to this issue after not working on the product f= or a while. I'm keeping the context all below, but the short version wa= s that we use TCPPING and, if someone removes a node with address X and, la= ter, starts a new cluster that includes the address, the old cluster keeps = trying to find its lost buddy at X.</div><div><br></div><div>We're stil= l back on v4.1.8 and I wanted to ask if the suggestion below, i.e. use TCPG= OSSIP or FILE_PING (this is for in-house deployments on their own networks)= is the most appropriate, and if there would be any benefit for this partic= ular issue by moving to v5.X? The way they run things now is to put host:po= rt info for each node in a file and then start the applications, which read= that file to set initial hosts. So FILE_PING might be the best for them so= that we don't need to have any new processes running.</div><div><br></= div><div>Thanks,</div><div>Bobby</div></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 26, 2021 at 3:26 AM Quest= ions/problems related to using JGroups via javagroups-users <<a href=3D"= mailto:[email protected]">[email protected]= eforge.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><br> <br> On 25.05.21 18:59, Questions/problems related to using JGroups wrote:<br> > On Tue, May 25, 2021 at 10:30 AM Questions/problems related to using <= br> > JGroups via javagroups-users <<a href=3D"mailto:javagroups-users@li= sts.sourceforge.net" target=3D"_blank">[email protected]= et</a> <br> > <mailto:<a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a>>> wrote:<= br> > <br> >=C2=A0 =C2=A0 =C2=A0Hi Bobby<br> >=C2=A0 =C2=A0 =C2=A0apologies for the delay!<br> > <br> > <br> > No problem -- thanks for looking.<br> > <br> > <br> >=C2=A0 =C2=A0 =C2=A0You cannot have the old cluster's initial_hosts= be 128,129,130 and the<br> >=C2=A0 =C2=A0 =C2=A0new one has the overlapping range 130,131.<br> > <br> > <br> > That's the problem. The customer has lots of nodes, clusters that = grow <br> > and shrink, and they're going to reuse the same IP addresses event= ually.<br> <br> <br> Then using TCPPING for the discovery is the wrong solution; it is <br> designed for a static cluster with a fixed and known membership.<br> <br> For the above requirements, I'd rather recommend:<br> * A dynamic discovery mechanism (TCPGOSSIP, FILE_PING, GOOGLE_PING etc)<br> * Emphemeral ports<br> * A new (different) cluster name for each new cluster that is started<br> <br> <br> >=C2=A0 =C2=A0 =C2=A0The old cluster will try to contact 130 (e.g. tryin= g to merge), thereby<br> >=C2=A0 =C2=A0 =C2=A0send its information to 130.<br> > <br> > <br> > Right, and what they want is some way to fully remove a node from a <b= r> > 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's <br> initial_hosts (TCPPING) and TCP's logical address cache. Either by <br> restarting, or by programmatically removing it. This can get complex <br> quickly though, as you'd have to maintain a list of ports per cluster.<= br> <br> The first solution above is much better IMO.<br> <br> <br> >=C2=A0 =C2=A0 =C2=A0What is it you're trying to achieve?<br> > <br> > <br> > Simply to take a node out of a cluster when it's not needed, then = later <br> > reuse the address of that node with a different cluster. If I change t= he <br> > cluster names (same port though) then I still get constant warnings, l= ike:<br> > JGRP000012: discarded message from different cluster <old> (our = cluster <br> > is <new>). Sender was <some addr><br> > <br> > We can suggest that they restart the cluster after removing a node, bu= t <br> > I don't know if that will work for them. I'll also try using d= ifferent <br> > ports for different clusters and see how that works for them.<br> <br> That will certainly work, but - again - you'd have to maintain ports <b= r> numbers for each cluster. Registration service? Excel spreadsheet?<br> <br> <br> > Given the size of the company in question, I can see that it might be = hard to <br> > coordinate that and eventually they'll get back in the same situat= ion <br> > where a previously used address is being used again with the same port= <br> > it used the last time.<br> <br> Right. So I have to come back to my suggestion of not using TCPPING!<br> Cheers,<br> <br> <br> > Thanks,<br> > Bobby<br> > <br> > <br> > <br> > _______________________________________________<br> > javagroups-users mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/javagroups-use= rs" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/list= s/listinfo/javagroups-users</a><br> > <br> <br> -- <br> Bela Ban | <a href=3D"http://www.jgroups.org" rel=3D"noreferrer" target=3D"= _blank">http://www.jgroups.org</a><br> <br> <br> <br> _______________________________________________<br> javagroups-users mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/javagroups-users" r= el=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/lis= tinfo/javagroups-users</a><br> </blockquote></div></div> --0000000000000f429905e0cc35e4-- --===============2536819582008943884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2536819582008943884== 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 --===============2536819582008943884==--