3:01 a.m.
Hey,
I've been working on JGroups bind settings for Keycloak Container Image
recently and we had a discussion with Stian about changing both binding
options and transport for JGroups.
As you probably know, we use standalone-ha.xml as a default configuration
for our image. This means, that Infinispan boots up in clustered mode. At
the moment, we use the default transport from the configuration, which is
UDP (with PING as discovery).
Even though UDP transport is a bit faster for larger clusters, it often
doesn't work out of the box in cloud environments (like AWS for the
instance). Of course, the JGroups stack can easily be changed by using the
`-Djboss.default.jgroups.stack=tcp` switch.
I'm planning to revise this piece and change the default transport to TCP
(probably by adding `-Djboss.default.jgroups.stack=tcp` switch to the
default options).
I also proposed, and would like to ask you to try it out, changing the bind
parameters to match IPv4 [1]. Previously, JGroups tried to bind to wrong
interfaces, including `fe80::5003:8eff:fefa:3e53%tap0` exposed by Podman.
Please have a look at the Pull Request [1], check if it works for you and
let me know what you think about using TCP as default transport for JGroups.
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/186
5:53 a.m.
Hi Sebastian,
I think going with TCP is fine. Looking at the PR, I am not sure using hostname -i to find
the local IP address is a good idea. Looking at the man page:
-i, --ip-address
Display the network address(es) of the host name. Note that this works only
if the host name can be resolved. Avoid using this option; use hostname --all-ip-addresses
instead.
while:
-I, --all-ip-addresses
Display all network addresses of the host. This option enumerates all
configured addresses on all network interfaces. The loopback interface and IPv6 link-local
addresses are omitted. Contrary to option -i, this
option does not depend on name resolution. Do not make any assumptions about
the order of the output.
I can imagine the second option might be more suitable, since it does not depend on DNS
and you want to exclude loopback interfaces anyways?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> Im
Auftrag von Sebastian Laskawiec
Gesendet: Donnerstag, 11. April 2019 10:02
An: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: [keycloak-dev] TCP for JGroups and bind options
Hey,
I've been working on JGroups bind settings for Keycloak Container Image recently and
we had a discussion with Stian about changing both binding options and transport for
JGroups.
As you probably know, we use standalone-ha.xml as a default configuration for our image.
This means, that Infinispan boots up in clustered mode. At the moment, we use the default
transport from the configuration, which is UDP (with PING as discovery).
Even though UDP transport is a bit faster for larger clusters, it often doesn't work
out of the box in cloud environments (like AWS for the instance). Of course, the JGroups
stack can easily be changed by using the `-Djboss.default.jgroups.stack=tcp` switch.
I'm planning to revise this piece and change the default transport to TCP (probably by
adding `-Djboss.default.jgroups.stack=tcp` switch to the default options).
I also proposed, and would like to ask you to try it out, changing the bind parameters to
match IPv4 [1]. Previously, JGroups tried to bind to wrong interfaces, including
`fe80::5003:8eff:fefa:3e53%tap0` exposed by Podman.
Please have a look at the Pull Request [1], check if it works for you and let me know what
you think about using TCP as default transport for JGroups.
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/186
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:55 a.m.
Hey Sebastian,
That's a very good idea actually!
I managed to test it out on Podman and here are the results:
$ hostname --all-ip-addresses
10.0.2.100 <-- This is exactly what we want!
$ hostname -i
fe80::2471:fff:fe12:682c%tap0 10.0.2.100 <-- This one requires filtering
Let me test it a bit more, but I guess, that's a step in good direction
(and this will simplify some code too). Thank you Sebastian!
Thanks,
Sebastian
On Thu, Apr 11, 2019 at 12:53 PM Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi Sebastian,
I think going with TCP is fine. Looking at the PR, I am not sure using
hostname -i to find the local IP address is a good idea. Looking at the man
page:
-i, --ip-address
Display the network address(es) of the host name. Note that
this works only if the host name can be resolved. Avoid using this option;
use hostname --all-ip-addresses instead.
while:
-I, --all-ip-addresses
Display all network addresses of the host. This option
enumerates all configured addresses on all network interfaces. The loopback
interface and IPv6 link-local addresses are omitted. Contrary to option -i,
this
option does not depend on name resolution. Do not make any
assumptions about the order of the output.
I can imagine the second option might be more suitable, since it does not
depend on DNS and you want to exclude loopback interfaces anyways?
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <
keycloak-dev-bounces(a)lists.jboss.org> Im Auftrag von Sebastian Laskawiec
Gesendet: Donnerstag, 11. April 2019 10:02
An: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: [keycloak-dev] TCP for JGroups and bind options
Hey,
I've been working on JGroups bind settings for Keycloak Container Image
recently and we had a discussion with Stian about changing both binding
options and transport for JGroups.
As you probably know, we use standalone-ha.xml as a default configuration
for our image. This means, that Infinispan boots up in clustered mode. At
the moment, we use the default transport from the configuration, which is
UDP (with PING as discovery).
Even though UDP transport is a bit faster for larger clusters, it often
doesn't work out of the box in cloud environments (like AWS for the
instance). Of course, the JGroups stack can easily be changed by using the
`-Djboss.default.jgroups.stack=tcp` switch.
I'm planning to revise this piece and change the default transport to TCP
(probably by adding `-Djboss.default.jgroups.stack=tcp` switch to the
default options).
I also proposed, and would like to ask you to try it out, changing the
bind parameters to match IPv4 [1]. Previously, JGroups tried to bind to
wrong interfaces, including `fe80::5003:8eff:fefa:3e53%tap0` exposed by
Podman.
Please have a look at the Pull Request [1], check if it works for you and
let me know what you think about using TCP as default transport for JGroups.
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/186
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1856
days inactive
1856
days old
2 comments
2 participants
participants (2)
-
Schuster Sebastian (INST-CSS/BSV-OS2) -
Sebastian Laskawiec