All,
I've been looking into this, and I think the problem is that all of the
link-local interfaces detected during this test are not actually routable:
fe80:0:0:0:2609:93a5:c4ac:15ea%utun7
fe80:0:0:0:926b:f264:7ec7:283e%utun6
fe80:0:0:0:4ab0:1734:75f8:c236%utun5
fe80:0:0:0:edc2:bbe0:ab0e:db71%utun4
fe80:0:0:0:898:f4ff:feb6:6b87%llw0
fe80:0:0:0:898:f4ff:feb6:6b87%awdl0
fe80:0:0:0:ce81:b1c:bd2c:69e%utun3
fe80:0:0:0:96b7:f229:b97f:3887%utun2
fe80:0:0:0:c055:a248:e218:ba6b%utun1
fe80:0:0:0:310c:b555:9669:572a%utun0
So even though Tomcat can bind to them, and you can create a URL to try
to connect, the OS will never route the packets as expected.
When checking all available interfaces on my machine, they all seem to
be IPv6 and all seem to be .. unusable to Tomcat?
If I hard-code the interface "fe80::1%lo0" into the unit test, it passes
immediately and successfully. But when left to its own devices, the test
will randomly pick one of the other interfaces and hang.
I think the testing environment is being sandboxed by the OS and so it
doesn't even see those other interfaces that I know exist. Instead, I
only see these useless tunneling interfaces. For example, "lo0" doesn't
show up, and "en0" doesn't show up -- the primary useful interfaces on
this machine.
So I wonder if we need some kind of workaround for MacOS.
Can anyone else with MacOS access confirm whether this is happening to them?
FYI I'm running MacOS Sequioia (15.6.1) and Temurin Java 25.0.1+8 (latest).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
