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
