On 01/08/17 20:00, Christopher Schultz wrote: > Mark, > > On 8/1/17 2:23 PM, Mark Thomas wrote: >> On 01/08/17 16:38, Christopher Schultz wrote: >>> Mark, >>> >>> On 8/1/17 8:01 AM, Mark Thomas wrote: >>>> On 30/07/17 13:39, Lazar Kirchev wrote: >>>>> Hello Mark, >>>>> >>>>> I tried with several thread dumps, but strange - I do not see >>>>> in them blocked/waiting threads. I attach two text files with >>>>> thread dumps. In both there can be seen the main thread in >>>>> AbstractEndpoint code, but it's RUNNABLE. I also attach a >>>>> screenshot from a profiling snapshot which shows similar >>>>> stacktraces. I am afraid these stacktraces do not help much. >>> >>>> <snip/> >>> >>>>> "main" #1 prio=5 os_prio=0 cpu=1593.75 [reset 1593.75] ms >>>>> elapsed=38.87 [reset 38.87] s allocated=27142056 B (25.88 >>>>> MB) [reset 27142056 B (25.88 MB)] defined_classes=2289 io= >>>>> file i/o: 8755720/5814 B, net i/o: 56/50 B, files opened:44, >>>>> socks opened:14 [reset file i/o: 8755720/5814 B, net i/o: >>>>> 56/50 B, files opened:44, socks opened:14 ] >>>>> tid=0x00000000028bd800 nid=0x40c0 / 16576 runnable >>>>> [_thread_blocked (_at_safepoint), >>>>> stack(0x0000000002920000,0x0000000002a20000)] >>>>> [0x0000000002a1e000] java.lang.Thread.State: RUNNABLE at >>>>> java.net.NetworkInterface.getAll()[Ljava/net/NetworkInterface;(Nati > ve >>>>> >>>>> >>> >>>>> > Method) >>> >>>> They help in so far as they point out whatever is going wrong, >>>> is going wrong in native code. They don't help point out where. >>>> My best guess is some form of network configuration issue >>>> where something isn't quite right and Java is timing out trying >>>> to perform some form of network operation. >>> >>>> I guess we could consider adding an explicit unlock address to >>>> be used when the Connector is listening on :: or 0.0.0.0 which >>>> would be used in preference to the current auto-detection. I'd >>>> prefer to understand why this isn't working though. >>> >>> I'm curious as to what's going on, here. Why do we need a >>> specific address to "unlock"? Can't we just unbind the socket and >>> be done with it ? >>> >>> If you use 0.0.0.0/:: and the "actual" interface bound ends up >>> being multiple interfaces, what then? There is no "one address" >>> from which we can unbind. > >> There is a thread blocked in an infinite wait to accept new >> connections. We need to make a connection to the server socket to >> 'unlock' (unblock would be better) that thread. That connection has >> to be to a specific IP address. When the Connector is bound to >> 0.0.0.0 or :: we need to figure out an actual address to connect >> to. > > Oh, so this is actually the process that runs when "catalina.sh stop" > is run? I was thinking that Tomcat was having trouble shutting-down > its own socket. Am I right in that it's the "Tomcat shutdown client" > that is timing out?
It looks like something in the native code that enumerates the network interfaces is timing out. > The catalina.out log posted makes it look like Tomcat gets the > "shutdown" message and then stalls trying to close its own sockets. > Does Tomcat, as part of its own shutdown process, need to make > outgoing/loopback connections? Yes. To unlock the acceptor thread(s). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
