paketo-buildpacks/libjvm

Add detection of IPv6 availability to debug

anthonydahanne opened this issue · 3 comments

Describe the Enhancement

Post Java 11, JVMs prefer to bind the debug port to IPv6 address rather than just IPv4 address.
It can cause problems in some environment where IPv6 is not available

Possible Solution

Detect if the JVM will be able to bind a port on IPv6, before setting the debug agent configuration

Current behavior

we have witnessed such issues in some IPv4-only environments (Bellsoft Liberica 17 - did not happen with 11): user sets BPL_DEBUG_ENABLED and then gets at application startup:

ERROR: transport error 202: socket creation failed: Address family not supported by protocol
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:734]
[[Command exited with 2]]

The (verified) workarounds in this case can be:

  • set JAVA_TOOL_OPTIONS to -Djava.net.preferIPv4Stack=true OR
  • not enable BPL_DEBUG_ENABLED and instead use JAVA_TOOL_OPTIONS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:5005 - so that the * wildcard does not translate to [::] by the JVM

Expected behavior

Ideally, libjvm would verify IPv6 is ok, and if not, replace * with 0.0.0.0 automagically

Another possible solution, suggested by @kdvolder , was to just check for the value of the kernel IPv6 support (see this article)
cat /sys/module/ipv6/parameters/disable

we could assert it worked fine in a testing environment that did not have ipv6 enabled


for the time being though, we're sill trying and opening a port on [::] to check if IPv6 is available

Either option sounds reasonable to me, but if I had to pick I'd be in favor of reading the kernel setting file. My concern with the testing option is that the test to attempt to open a port on an IPv6 address will be slower than just reading from a file.

Either check will need to happen at runtime to be effective, so anything we're doing is going to block the application start-up and make it seem to take longer to start up. People are obsessed with fast start-up time at the moment, so I feel like this is an area where we need to be careful. If one of the option is faster, then we should probably take that option.

@dmikusa gotcha!

I've implemented and tested the new fix: #366