DNS_PING self-discovery bug?

[FlorianVielhauer]

Hi,

While trying to build a cluster for keycloak using DNS_PING mode from jgroups, I observse the following in the logs:

[0m[32m09:41:09,100 DEBUG [org.jgroups.protocols.pbcast.GMS] (ServerService Thread Pool -- 58) address=ec1aa4cfd54b, cluster=ejb, physical address=10.0.18.192:7600

[0m[32m09:41:09,102 DEBUG [org.jgroups.protocols.dns.DNS_PING] (ServerService Thread Pool -- 58) ec1aa4cfd54b: entries collected from DNS (in 1 ms): [10.0.18.192:0, 10.0.18.191:0]

[0m[32m09:41:09,102 DEBUG [org.jgroups.protocols.dns.DNS_PING] (ServerService Thread Pool -- 58) ec1aa4cfd54b: sending discovery requests to hosts [10.0.18.192:0, 10.0.18.191:0] on ports [7600 .. 7600]

When I check DNS_PING.java there are the following lines (141/142):

if (address.equals(physical_addr)) // no need to send the request to myself

Questions:

1. How can this condition ever be satisfied? The address comparison includes the port as well and DNS entries don't have a port => So the discovery request is also send to "myself". Or am I missing something?

2. Can "send the request to myself" lead to a broken cluster? In my case I am receiving "ec1aa4cfd54b: haven't received a heartbeat from 2b5d9e36ee3d for 64018 ms, adding it to suspect list" but I am not sure if this is related to the "self-discovery" as the log message is about a missing heartbeat from the peer.

BR,
Florian

[belaban]

1. In case of SRV entries (not A entries), DNS records do include the port. I might be mistaken, though...
2. No, messages sent to self should not lead to broken clusters. In your example, a member has not received a heartbeat from another member, and is therefore suspecting it. This is the normal way to suspect and exclude a non-responsive (or crashed) member.

[FlorianVielhauer]

Yes, you are right about SRV DNS entries. In my environment (docker swarm) the DNS entries are unfortunately A entries. Good to know that this doesn't break the cluster.

In the meantime we resolved our issue. We had inconsistent MTU settings in our docker swarm environment and that was the reason why the cluster wasn't build. Now everything is working fine.

Thanks for fast response!

[belaban]

Good to know it works now