You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Lazar Kirchev <la...@gmail.com> on 2017/07/28 05:53:42 UTC
Tomcat 8 slow shutdown on Windows 10
Hello,
I am observing slow shutdown of Tomcat 8 on Windows 10 - some 9 - 11
seconds. I observed this first with Tomcat 8.5.16, but then checked it on
older versions and I found the same from 8.5.11 onward. Before that it
stops for less than a second.
Most time is spent in stopping the protocol handlers - about 2 seconds for
each. Profiling shows that the waiting is in the
java.net.NetworkInterface.getNetworkInterfaces() method in AbstractEndpoint
class.
However, one strange thing is that I observe this behavior when I am
connected to one network, bot on another network the delay is not observed
and the server stops for less than a second.
Has anybody experienced similar problems?
Regards,
Lazar
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Suvendu Sekhar Mondal <su...@gmail.com>.
Lazar,
> I am observing slow shutdown of Tomcat 8 on Windows 10 - some 9 - 11
> seconds. I observed this first with Tomcat 8.5.16, but then checked it on
> older versions and I found the same from 8.5.11 onward. Before that it
> stops for less than a second.
>
</snip>
>
> Has anybody experienced similar problems?
>
I recently started using Tomcat 8.0.20 on Windows 10 and it takes more
than 1.5-2min to stop. This is much slower than 7.0.55. I thought it's
only happening on my system until I saw your mail. :)
I can see that you have already shared some thread dumps. Let me
collect some data during this slowdown. Wanted to see if it shows the
same hotspot or not.
Thanks!
---------------------------------------------------------------------
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
Re: Tomcat 8 slow shutdown on Windows 10
Posted by Mark Thomas <ma...@apache.org>.
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 Lazar Kirchev <la...@gmail.com>.
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.
In tomcat_threaddump.txt the main thread is in socket.connect() and in
tomcat.threaddump_1.txt it is in NetworkInterfaces.getAll(). On the
screenshot both can be seen.
Here is the output from Tomcat shutdown, showing that it stops for 9
seconds, 2 seconds for stopping each of the two protocol handlers:
30-Jul-2017 15:31:29.562 INFO [main]
org.apache.catalina.core.StandardServer.await A valid shutdown command was
received via the shutdown port. Stopping the Server instance.
30-Jul-2017 15:31:29.565 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["http-nio-8080"]
30-Jul-2017 15:31:31.810 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["ajp-nio-8009"]
30-Jul-2017 15:31:34.098 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
[Catalina]
30-Jul-2017 15:31:34.160 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio-8080"]
30-Jul-2017 15:31:36.405 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["ajp-nio-8009"]
30-Jul-2017 15:31:38.717 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["http-nio-8080"]
30-Jul-2017 15:31:38.725 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["ajp-nio-8009"]
In any case, if the attachments are not delivered, here are the stacktraces
of the main thread from the two thread dumps:
"main" #1 prio=5 os_prio=0 cpu=1390.63 [reset 1390.63] ms elapsed=110.34
[reset 110.34] s allocated=27153968 B (25.90 MB) [reset 27153968 B (25.90
MB)] defined_classes=2292
io= file i/o: 8758881/5694 B, net i/o: 56/48 B, files opened:44, socks
opened:15 [reset file i/o: 8758881/5694 B, net i/o: 56/48 B, files
opened:44, socks opened:15 ]
tid=0x0000000000dce800 nid=0x3ca8 / 15528 runnable [_thread_blocked
(_at_safepoint), stack(0x0000000002560000,0x0000000002660000)]
[0x000000000265e000]
java.lang.Thread.State: RUNNABLE
at java.net.DualStackPlainSocketImpl.waitForConnect(II)V(Native
Method)
at
java.net.DualStackPlainSocketImpl.socketConnect(Ljava/net/InetAddress;II)V(DualStackPlainSocketImpl.java:85)
at
java.net.AbstractPlainSocketImpl.doConnect(Ljava/net/InetAddress;II)V(AbstractPlainSocketImpl.java:345)
- locked <0x00000000eb77ea68> (a java.net.DualStackPlainSocketImpl)
at
java.net.AbstractPlainSocketImpl.connectToAddress(Ljava/net/InetAddress;II)V(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(Ljava/net/SocketAddress;I)V(AbstractPlainSocketImpl.java:188)
at
java.net.PlainSocketImpl.connect(Ljava/net/SocketAddress;I)V(PlainSocketImpl.java:173)
at
java.net.SocksSocketImpl.connect(Ljava/net/SocketAddress;I)V(SocksSocketImpl.java:392)
at
java.net.Socket.connect(Ljava/net/SocketAddress;I)V(Socket.java:591)
at
org.apache.tomcat.util.net.AbstractEndpoint.unlockAccept()V(AbstractEndpoint.java:833)
at
org.apache.tomcat.util.net.NioEndpoint.stopInternal()V(NioEndpoint.java:280)
at
org.apache.tomcat.util.net.AbstractEndpoint.stop()V(AbstractEndpoint.java:1041)
at
org.apache.coyote.AbstractProtocol.stop()V(AbstractProtocol.java:695)
at
org.apache.catalina.connector.Connector.stopInternal()V(Connector.java:1047)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c029b3b8> (a
org.apache.catalina.connector.Connector)
at
org.apache.catalina.core.StandardService.stopInternal()V(StandardService.java:498)
- locked <0x00000000c02aecc8> (a java.lang.Object)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c029aa08> (a
org.apache.catalina.core.StandardService)
at
org.apache.catalina.core.StandardServer.stopInternal()V(StandardServer.java:814)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c017a540> (a
org.apache.catalina.core.StandardServer)
at org.apache.catalina.startup.Catalina.stop()V(Catalina.java:729)
at org.apache.catalina.startup.Catalina.start()V(Catalina.java:691)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(DelegatingMethodAccessorImpl.java:43)
at
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Method.java:497)
at
org.apache.catalina.startup.Bootstrap.start()V(Bootstrap.java:355)
at
org.apache.catalina.startup.Bootstrap.main([Ljava/lang/String;)V(Bootstrap.java:495)
Locked ownable synchronizers:
- None
And:
"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)
at
java.net.NetworkInterface.getNetworkInterfaces()Ljava/util/Enumeration;(NetworkInterface.java:343)
at
org.apache.tomcat.util.net.AbstractEndpoint.getUnlockAddress(Ljava/net/InetSocketAddress;)Ljava/net/InetSocketAddress;(AbstractEndpoint.java:877)
at
org.apache.tomcat.util.net.AbstractEndpoint.unlockAccept()V(AbstractEndpoint.java:818)
at
org.apache.tomcat.util.net.NioEndpoint.stopInternal()V(NioEndpoint.java:280)
at
org.apache.tomcat.util.net.AbstractEndpoint.stop()V(AbstractEndpoint.java:1041)
at
org.apache.coyote.AbstractProtocol.stop()V(AbstractProtocol.java:695)
at
org.apache.catalina.connector.Connector.stopInternal()V(Connector.java:1047)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c02af208> (a
org.apache.catalina.connector.Connector)
at
org.apache.catalina.core.StandardService.stopInternal()V(StandardService.java:498)
- locked <0x00000000c02b1150> (a java.lang.Object)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c02af0f0> (a
org.apache.catalina.core.StandardService)
at
org.apache.catalina.core.StandardServer.stopInternal()V(StandardServer.java:814)
at
org.apache.catalina.util.LifecycleBase.stop()V(LifecycleBase.java:226)
- locked <0x00000000c0175970> (a
org.apache.catalina.core.StandardServer)
at org.apache.catalina.startup.Catalina.stop()V(Catalina.java:729)
at org.apache.catalina.startup.Catalina.start()V(Catalina.java:691)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(DelegatingMethodAccessorImpl.java:43)
at
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Method.java:497)
at
org.apache.catalina.startup.Bootstrap.start()V(Bootstrap.java:355)
at
org.apache.catalina.startup.Bootstrap.main([Ljava/lang/String;)V(Bootstrap.java:495)
Locked ownable synchronizers:
- None
Kind regards,
Lazar
On Fri, Jul 28, 2017 at 2:49 PM, Mark Thomas <ma...@apache.org> wrote:
> On 28/07/2017 06:53, Lazar Kirchev wrote:
> > Hello,
> >
> > I am observing slow shutdown of Tomcat 8 on Windows 10 - some 9 - 11
> > seconds. I observed this first with Tomcat 8.5.16, but then checked it on
> > older versions and I found the same from 8.5.11 onward. Before that it
> > stops for less than a second.
> >
> > Most time is spent in stopping the protocol handlers - about 2 seconds
> for
> > each. Profiling shows that the waiting is in the
> > java.net.NetworkInterface.getNetworkInterfaces() method in
> AbstractEndpoint
> > class.
> >
> > However, one strange thing is that I observe this behavior when I am
> > connected to one network, bot on another network the delay is not
> observed
> > and the server stops for less than a second.
> >
> > Has anybody experienced similar problems?
>
> That code is there so Tomcat can find the right address to use to unlock
> the connector when it is bound to '0.0.0.0' or '::'.
>
> The problems I recall in the past have been around whether that code
> identifies the right address to use to unlock the connector. The code
> has been tweaked a couple of times to handle those.
>
> The problem you describe appears to be different.
>
> Can you get a stack trace of the thread when it is waiting? That might
> shed some light on what is taking so long.
>
> Kind regards,
>
> 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 28/07/2017 06:53, Lazar Kirchev wrote:
> Hello,
>
> I am observing slow shutdown of Tomcat 8 on Windows 10 - some 9 - 11
> seconds. I observed this first with Tomcat 8.5.16, but then checked it on
> older versions and I found the same from 8.5.11 onward. Before that it
> stops for less than a second.
>
> Most time is spent in stopping the protocol handlers - about 2 seconds for
> each. Profiling shows that the waiting is in the
> java.net.NetworkInterface.getNetworkInterfaces() method in AbstractEndpoint
> class.
>
> However, one strange thing is that I observe this behavior when I am
> connected to one network, bot on another network the delay is not observed
> and the server stops for less than a second.
>
> Has anybody experienced similar problems?
That code is there so Tomcat can find the right address to use to unlock
the connector when it is bound to '0.0.0.0' or '::'.
The problems I recall in the past have been around whether that code
identifies the right address to use to unlock the connector. The code
has been tweaked a couple of times to handle those.
The problem you describe appears to be different.
Can you get a stack trace of the thread when it is waiting? That might
shed some light on what is taking so long.
Kind regards,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org