On 28/04/2013 15:01, Konstantin Kolinko wrote: > 2013/4/28 Konstantin Kolinko <knst.koli...@gmail.com>: >> 2013/4/28 Mark Thomas <ma...@apache.org>: >>> On 28/04/2013 14:19, ma...@apache.org wrote: >>>> Author: markt >>>> Date: Sun Apr 28 13:19:48 2013 >>>> New Revision: 1476761 >>>> >>>> URL: http://svn.apache.org/r1476761 >>>> Log: >>>> Improve logging by naming the Servlet that hasn't stopped. >>> >>> I'm currently looking at the trunk unit test failures with buildbot. I'm >>> not at all sure what is going on. The logs suggest threads are getting >>> stuck for extended periods of time (minutes in some cases) but it always >>> seems to happen with the same tests. >>> >>> The delays are too long for GC but they could be swapping related as >>> buildbot is running on a VM. If that were the case I'd expect to see >>> more variation in the test failures though. >>> >>> At the moment I am looking at improving the logging which has the added >>> benefit of being useful to our users as well. >>> >>> What I really need is the ability to trigger a thread dump from within >>> the JVM. While there are ways of doing it, none of them are particularly >>> simple. I might look into this if the logging doesn't get me anywhere. >>> >>> >>> Suggestions - and better still help - welcome. >>> > > 1. > >> There exists Thread.getStackTrace() @since 1.5 that can get >> stacktrace from a different thread. >> >> I thought it could be a good addition to our WebAppLoader report of >> non-stopped threads. >> >> There exists static method Thread.getAllStackTraces(): Map<Thread, >> StackTraceElement[]>.
+1 > 2. Maybe change default logging configuration to use OneLineFormatter. > It will give us thread names in the log, > > Alternatively, there appears to be a way to customize the pattern used > by SimpleFormatter > http://tomcat.markmail.org/thread/dxvweaxzkgwjymai > ("Cannot apply simpleformtatter pattern to catalina.sh" thread from Jan 2013) > > 3. "Read time out" errors > http://ci.apache.org/projects/tomcat/tomcat8/logs/1476401/TEST-org.apache.catalina.loader.TestVirtualContext.BIO.txt > http://ci.apache.org/projects/tomcat/tomcat8/logs/1476401/TEST-org.apache.catalina.loader.TestVirtualContext.NIO.txt > > What is strange is that the whole Tomcat startup and shutdown appears > to be faster > than timeout value reported by client thread > (read fails after 12 and 9 seconds and Tomcat goes up and down in 10 and 7). The read fails after 3s. The 12s and 9s figures are for the entire test. > 4. > http://ci.apache.org/projects/tomcat/tomcat8/logs/1476401/TEST-org.apache.catalina.core.TestAsyncContextImpl.BIO.txt > > says > "java.lang.IllegalStateException: Calling [asyncDispatch()] is not > valid for a request with Async state [MUST_COMPLETE]" > > There is no such message in NIO test. Haven't looked into this yet but it looks possible this might have the same root cause. Fundamentally, the VM running the tests appears to have quite big IO delays. This is triggering failures in some timing related tests. I suspect there isn't much we can do about this short of buying new hardware. I'll stick my infra hat on and take a look at the VM host. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
