java.net.preferIPv4Stack causing delays on IPv6 enabled hosts

[gionn]

Configuring NGINX with locahost has the side effect of causing errors when trying the IPV6 [::1] loopback address, which is the preferred by the system, because Tomcat is only listenting on IPv4 because of the use of the java.net.preferIPv4Stack directive. Connections eventually succeed because NGINX then tries the 127.0.0.1 address that is resolved too, but it is at minimum an annoyance that polutes the error log, and can be seen too as a performance degradation issue, though minimal.

We'd like to know if there's some profound reason for explicitly restricting Tomcat to use IPv4, before goin on and removing that flag to make IPv6 connections work.

Originally posted by @jalvarezferr in #758 (comment)

[gionn]

We'd like to know if there's some profound reason for explicitly restricting Tomcat to use IPv4

it's there since years, I guess it's a workaround for hosts with IPv6 not properly configured, but the proper fix is usually to disable IPv6 via net.ipv6.conf.all.disable_ipv6 = 1 and not on a per-process basis.

I guess we can do some cleanup of all the java.net.preferIPv4Stack and see what happens.

[alxgomz]

Setting net.ipv6.conf.all.disable_ipv6 sounds very intrusive.
IIRC the java option was introduced to circumvent issues with some clustering stack (probably jgroup at that time). It's worth testing again without this option but I'm not for setting /proc/sys/ params unless that really prevents the system from working (which is not the case here)

[jalvarezferr]

I agree that disabling IPv6 at the OS level through net.ipv6.conf.all.disable_ipv6 = 1 can't be the solution. It has many potential implications to other system services, and it is contrary to general good principle of using IPv6.

[gionn]

I apologize for any confusion caused by my previous message: my intention was not to propose a global disabling of IPv6 in the playbook. Instead, I was referencing it as a potential solution for users encountering issues related to IPv6 misconfiguration on their own hosts.

The primary focus remains on resolving the existing issue by removing all occurrences of java.net.preferIPv4Stack since hosts network configuration should not be really a concern of this playbook.

[alxgomz]

tracked in OPSEXP-2536

[alxgomz]

should be resolved in 2.6.0