Just to follow up on this.
I tripped over a related issue today running the Tomcat unit tests for
9.0.x. Being able to reproduce it gave me a chance to dig further and
come up with a better fix. These interfaces are marked as "point to
point" interfaces which Java can see so we can skip them. I've updated
the unlock code and the fix will be in the July release round.
Mark
On 26/02/2024 15:59, Michał Szymborski wrote:
Thank you, that clears things up. I did not think about implication of
using wildcard. I will try to use explicit addresses from now on. You
learn something new every day!
Cheers,
Michał
On 26.02.2024 09:48, Mark Thomas wrote:
On 25/02/2024 18:18, Michał Szymborski wrote:
<snip/>
On quick inspection the acceptor thread
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033]
, which was correctly picked up at first, but then this local address
got transformed:
0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use
that address to establish a connection to the Acceptor thread so it
has to try and deduce a valid IP local address from the network
configuration information exposed through the Java APIs.
https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164
It started picking up interfaces to use, and it stopped at the first
non-loopback non-link local address, which also happens to be some
sort of a bridge network for one of my VMs. I don't quite know why
there is no routing set up, but this interface should not have been
picked in the first place.
It is a local IP address so as far as Tomcat can see it should be
valid to connect to the Acceptor.
<snip/>
I'll take a look at how it works on my work laptop with MacOs, but
I'd wager a guess that some corporate VPNs have interfaces which have
messed up routing as well. Can't tell if it's a bug or a feature, but
it sure is unexpected. Making this timeout for acceptor shutdown
configurable would be one sort of band-aid.
It is configurable. socket.unlockTimeout. Documented default is 250ms
although looking at the code it appears there is a minimum of 2000ms -
need to see why that is.
Configuring a specific address (even 127.0.0.1) for the Connector
would also address this.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
