You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2017/08/01 12:01:09 UTC
Re: Tomcat 8 slow shutdown on Windows 10
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;(Native
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Mark Thomas <ma...@apache.org>.
On 02/08/17 14:57, Christopher Schultz wrote:
> Mark,
>
> On 8/1/17 4:17 PM, Mark Thomas wrote:
>>>> 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'.
>
> Is this because of the use-case above when we are merely "pausing" the
> connector? Or is this because, even when shutting-down, we don't want
> to close the socket and terminate any in-flight requests?
Bit of both. We want to stop any new requests while allowing in-flight
requests to continue (for whatever the allowed perios is - 10s I think).
> When playing-around with JMX and the connectors, I found sending a
> "stop" request to the connector immediately kills all in-flight
> connections. Is there an operation that is not available through JMX
> that is being called here? Like "shutdown"?
I'd expect the in-flight requests to complete and then close but idle
keep-alive connections to close pretty much immediately.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/1/17 4:17 PM, Mark Thomas wrote:
>>> 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'.
Is this because of the use-case above when we are merely "pausing" the
connector? Or is this because, even when shutting-down, we don't want
to close the socket and terminate any in-flight requests?
When playing-around with JMX and the connectors, I found sending a
"stop" request to the connector immediately kills all in-flight
connections. Is there an operation that is not available through JMX
that is being called here? Like "shutdown"?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZgdo3AAoJEBzwKT+lPKRYBbkP/2JpQj5ajEAH0m7efIaz5wRb
MDM5q5nMqNDeVu4gykhrd4V8qR7MucAubKfvqbo2W1wB7dTCaWFQ8GQD/5wG2QT/
5x5MkjrITq1Uw0DHKUGmXtRAb9oE/44jdBj+MjIkq0oRRF9/Vrk1fMczVKs05vXT
xoY2yVwgRGAv1pD2QkIDgUYt1l/PegLO4UFZzY9F2vF8P1gaEOmpjFgOwAf1T75u
ZMBpk8KSOiWcV493eqad4GV2pSISTIFNuqeV3XzVlowRooUj3DxvzzOJnOlaKPG9
r/Q9TC8tRi/h2j2sGlrJazvlZHpfmGy/l4PZpsTfaHgJHn/Go9f909cqjWLL8796
LouEM7eQYYx6wv+DnDSshgincptFUxll8iw+c6QKJ5d0r6IOwdczXI1vRtDn4VOr
swatboD3s2XSVCSzdfRA5ZO84/qxFURJQKOD88UYIbh7XmVCZ+V8bQwOvueRCvkj
JCoX2piMdW8LZhUH675CjJWnJcqMk6lck76J3FFfziDtD3t7pin5hSGT2XrJGR4E
QcN7O8IGPk9T4Q/adhWP88aIOyE8+/HuF4jCYXRHB2lP3xDBQLezUslziy59u8gi
XwSjMw0Cz/G9KMPht0jAvQQoWWllZbqoOW4B7CjF69sN8czfdP9hHBgbIHT4pkIc
+tx4Xk7rkUC6P/cVZgZm
=+ZCw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Mark Thomas <ma...@apache.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Mark Thomas <ma...@apache.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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?
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?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZgM/lAAoJEBzwKT+lPKRYB0IP/3Du3msPeN+6bRBGLQ+MqRPt
+VqColRN8b4hq1eprl6YhpxhBRwR02skCO85NB2dfUXzXrJnin+gF8iJAHmnx2nn
1/lt2ABD8zI+8IzH8Kr3ZosF7e9T+cSRLoKkS+dvT+9L2ngQE8f6WNWiXlZm1AQm
TgtpdJrwOSL3U8Lg548DsBjizqedx+AIhEUmhGxWnucmxtumwgTvZkKj0JTmd332
QwgwozfiO4qiAt6wlhLC3/YYjVbxdwC3GV3QJSl6a3YkslloUh3FpWDGxQ6+MfiB
stG+5x/8pQC13IokS7V677u2rymPRti2ns8cPtO/UGPdcLB2uccn6L2HHXF1xX5D
kgFji7W33FVBxZ9WrB8z/nfh0KAtvSM3HmAzjaN9zCWJsRriplKNTVjM/VuNTOg7
tPTIWxJIjT6McMlI8eXU0Zw9xv9W9nhTMGVWhanZtgrFFGtgXGvp9xbfUN22gi8c
2K4+QaDdkSNmKvV4kvVsKMCVllWJAzoYLklOMgWI7Mxt/F6QCnva5j/kUL0xuZtY
dJDW2sSeiV5PNqUarJrvWx6yGkUqZXGd7lk3l+hDKGyZmQ4UTAP0UZWFXUTDpGnV
9EtIinj/S1fjX2nWQ+ik8ehMrM462X0NghA0d91rleCjqGsMt5XQ+Gl2XG1GM/kN
fHmkUh+zDKtfFlAZSXNt
=LnKb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Mark Thomas <ma...@apache.org>.
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;(Native
>>>
>>>
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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;(Native
>>
>>
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZgKBaAAoJEBzwKT+lPKRYKfIP/12HEZ0mqsddyFN3UzgQAcJt
FLZvPxx3nOjOIWzSSeBAMdHQHUlexQWx7pzmqQG2ANpY6VeOGuIbn7EMwF667IWh
p1CYyn3GDLiobPGaT/u0GEK1wipRWsnWI1U+IJSZjLIb13Rc/KIzfPXWUqq7GUDO
x2joF8KCzDEpHN3mPUNP+fVaIBZh/oQYGwIFuJsWKJdxr2hPLELeAM1g+vkP3Wgy
xgne3uHOn8v3q0CUBFfpbG0Nf9JeyqMnNfuVuBA+bxs35HYv4FUXQ0bPy8opPUwk
T7pAyyMQNydxMPUVPwBsY+Kbl01yNiE96rEGDCIwBzewXDfKK4KwoiWp9Upj2DYt
l3TSO4OrHCGmAi0iRub5z9aa02gAa4wLzPR74ORv1DdTNG2u/kC4jqoawLBNPHNj
qvx/8TZ/2OBkzy0Hawekx5QmAH06lp+0mw4/3loz0ngKQefrWe4NuC5l8s6a7vct
cmJzpg/zhHYIyv/qYN0NedYrLOQZKe3+pdNLkipG7yWdxAX5pQdZ1Nt0HTkxTyyt
sYD8y39WbcKcFhQlqSjWXC1/Ux63Hysxd4mkKTJG7CKFpHh1IvbaPd/6nc6+c5kz
7iXnRxrYp369/OHAxLC5ZGqGHqktBvc1M/RQ1+5eCOFFE63zYyQCA1FwT/Du29kX
XyNxKN4vbM72NmFszRWN
=kQAY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org