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