-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 8/1/17 3:10 PM, Mark Thomas wrote: > 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;(Na ti >> >>>>>> 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)*. (Emphasis mine) I understand, now. Thanks. Will a Thread.interrupt() not work? What about calling socket.close() from the shutdown thread? That should cause a SocketException to be thrown by accept()[1]. If it's an NIO SocketChannel, then we can close the channel itself and cause an I/O interrupt.[2] - -chris [1] https://stackoverflow.com/a/2983860/276232 [2] https://stackoverflow.com/a/12315392/276232 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZgNV/AAoJEBzwKT+lPKRYQe0P/0mEXuYmtDUQkgzIwxRIbSnf pN4s1UQCd7ZLEd9hprFCKLdke22FJbvT6j4NSyRojcJl/kJsF7cGpVWHCCbMCJEv YGLw+VwsI8TVs4J0q2g7soGM0oE9yD5IYQRsQWuRvAzt3eiEOQaTiPGEgQ4zQuEi DxPK4ThYQJ141bvoUkEkFCqdL0O4njYT2z9PVs4bnLiH7ASVSkPUfamnX3bbXVlR 2WJ6gkkf5WDzBR0DGeuP/VrSohi+hcXdUwShmjjCjxVQlu6pRbz9p04vwJI0v1MP kAF4Qc1JEGtt2yj/EwWsIwuBv/jXHB6UuGTkhIVILPySKFmH0iA9zPCoBMERpKum oui3h+hQPM+jYJxJ5F3ocrmWarMa+9H60kQRdrkd5Re+gxng+e6hvt4yKu4snQD5 /ourOL+GjeMX72mWcMtgvay0vC8RVFKZIciaPP6CnquMMZyLxlU1WrgCEuZmXLBj BfN3vOcFubj+oUdgLv08PePSSLTX2LbEmzH+2ZUwfVd7z7yMg//FqSY/sHwWTCkk +cqmcuxmqM1ya0yof2BSQ4KHpp/AXdzi1tA7B2xGn2mVh6OYftW9fYE6kTUowadB 6EKBqq35GhqEltUle+fmNzqWvZdv8ZAjDomV2bm0lEuBbNspAlYXSvQciCT7mlv4 kO3q1Oer/TOlgO8gCZ/0 =zywb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
