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

--===============3987880362858507331==
Content-Type: multipart/alternative; boundary="00000000000065493a05bf3fda05"

--00000000000065493a05bf3fda05
Content-Type: text/plain; charset="UTF-8"

Hi,

Our product uses the TCP stack with jgroups 4.1.8. It gets set up by end
users through a configuration file that contains (among other things), a
list of IP addresses for a node to connect to when joining a cluster. We
set this for TCPPING.initial_hosts.

If they have a wrong address at startup they end up getting JGRP000032
warnings filling the logs. For instance, the following leads to logs
filling on two nodes, one of which was set up correctly:

1. Start cluster A/B. A is the coordinator.
2. Start a one-node cluster C.
3. On node D, include addresses for D and B in the initial hosts list and
attempt to join.
4. D will join C for a cluster C/D and, obviously, not join A/B since it
didn't attempt to connect to the coordinator.

After this, the logs for D will fill with:
WARN: JGRP000032: <D>: no physical address for <A>, dropping message

...and B logs will fill with:
WARN: JGRP000032: <B>: no physical address for <C>, dropping message

I know this is a setup error on the user's side, but was wondering if
there's anything we could add programmatically to stop it. For instance,
when they see the logs on X filling up with messages about Y in another
cluster, is there something we could do to tell X to forget Y exists? It's
not enough just to stop/fix/start that cluster, as (in the case of A/B
above) the cluster that was started correctly could be showing this
problem. For some customers, getting a maintenance window to shut down all
related clusters and restart them is a problem.

For that matter, is there anything programmatically we could do to detect
that this is happening? Besides parsing the jgroups logging output I mean.

Thank you,
Bobby

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

<div dir=3D"ltr">Hi,<div><br></div><div>Our product uses the TCP stack with=
 jgroups 4.1.8. It gets set up by end users through a configuration file th=
at contains (among other things), a list of IP addresses for a node to conn=
ect to when joining a cluster. We set this for=C2=A0TCPPING.initial_hosts.<=
/div><div><br></div><div>If they have a wrong address at startup they end u=
p getting=C2=A0JGRP000032 warnings filling the logs. For instance, the foll=
owing leads to logs filling on two nodes, one of which was set up correctly=
:</div><div><br></div><div>1. Start cluster A/B. A is the coordinator.</div=
><div>2. Start a one-node cluster C.</div><div>3. On node D, include addres=
ses for D and B in the initial hosts list and attempt to join.</div><div>4.=
 D will join C for a cluster C/D and, obviously, not join A/B since it didn=
&#39;t attempt to connect to the coordinator.</div><div><br></div><div>Afte=
r this, the logs for D will fill with:</div><div>WARN: JGRP000032: &lt;D&gt=
;: no physical address for &lt;A&gt;, dropping message<br></div><div><br></=
div><div>...and B logs will fill with:</div><div>WARN: JGRP000032: &lt;B&gt=
;: no physical address for &lt;C&gt;, dropping message<br></div><div><br></=
div><div>I know this is a setup error on the user&#39;s side, but was wonde=
ring if there&#39;s anything we could add programmatically to stop it. For =
instance, when they see the logs on X filling up with messages about Y in a=
nother cluster, is there something we could do to tell X to forget Y exists=
? It&#39;s not enough just to stop/fix/start that cluster, as (in the case =
of A/B above) the cluster that was started correctly could be showing this =
problem. For some customers, getting a maintenance window to shut down all =
related clusters and restart them is a problem.</div><div><br></div><div>Fo=
r that matter, is there anything programmatically=C2=A0we could do to detec=
t that this is happening? Besides parsing the jgroups logging output I mean=
.</div><div><br></div><div>Thank you,</div><div>Bobby</div><div><br></div><=
/div>

--00000000000065493a05bf3fda05--


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


--===============3987880362858507331==
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

--===============3987880362858507331==--