[
https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin....
]
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)