[jboss-jira] [JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery

[Sebastian Łaskawiec (Jira)]

    [ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669329#comment-13669329 ] 

Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------

In short, this should never happen in Kubernetes.

In my opinion, things like {{FD_SOCK.bind_port=0}} should never be set in containers. In vast majority of the cases, you don't need dynamic ports since with a "Bridged" network setup (which is the default in Kubernetes), you can have multiple containers exposing the same port. The only exception from this rule is a setup with "Host" network setting. In that case, the port clash may occur. However, in most of the cases (Tectonic, OpenShift Online etc), you can not use it.

So just to recap, the "blessed" setup is this: 
* You assign a static port for JGroups. It can be anything you want since multiple container can use the same port. 
* The next step is to {{EXPOSE}} it in your Dockerfile. 
* Finally, you create a Service, which basically exposes a port specified in a Dockerfile for the consumption inside a Kubernetes cluster. 

Just to give you an example based on your snippet, a DNS {{SRV}} could look like this (I'm handcrafting this based on a snippet from my previous comment):
{code}
$ dig jgroups.dev.auth.example.com.svc.cluster.local SRV
 
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.example.com.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16690
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;jgroups.dev.auth.example.com.svc.cluster.local. IN SRV
 
;; ANSWER SECTION:
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.example.com.svc.cluster.local.
 
;; Query time: 2 msec
;; SERVER: 10.42.3.2#53(10.42.3.2)
;; WHEN: Fri Sep 21 01:45:44 2018
;; MSG SIZE  rcvd: 481
{code}

The key point to notice is that all ports are {{8888}}. 

> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
>                 Key: JGRP-2316
>                 URL: https://issues.jboss.org/browse/JGRP-2316
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.15
>            Reporter: dmcnair
>            Assignee: Bela Ban
>            Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records.  While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)