On 01/08/17 20:24, Christopher Schultz wrote: > > > 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.
The acceptor is also unlocked when a Connector is paused (i.e. when the server socket is NOT closed but it stops accepting new connections). > Will a Thread.interrupt() not work? For APR probably not. It might work for NIO but reading the Javadoc for accept() suggests an interrupt would close the connection (not what we want) > 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] We need to be able to do this without closing the socket. It is that requirement that makes this 'interesting'. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
