-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
