Closed anthonydahanne closed 7 months ago
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: https://github.com/paketo-buildpacks/libjvm/pull/366
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:The (verified) workarounds in this case can be:
JAVA_TOOL_OPTIONS
to-Djava.net.preferIPv4Stack=true
ORBPL_DEBUG_ENABLED
and instead useJAVA_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 JVMExpected behavior
Ideally,
libjvm
would verify IPv6 is ok, and if not, replace*
with0.0.0.0
automagically