On 05.09.2010 04:19, Kevin wrote:
Hi, I'm using Apache Bench (ab) to send 1,000 requests with a
concurrency of 500 to a simple servlet on Tomcat trunk (revision 992708,
2010-09-03) which uses request.startAsync() and
Executors.newFixedThreadPool(10) to do the work and return a few bytes
of response and asyncContext.complete().
What I'm noticing is that every once in a while there is an errant
request that takes up to 10 seconds, while the average is around half a
second. I've reproduced this on both Oracle and IBM JVMs. I've looked at
verbosegc and see no anomalies in pause times or heap usage. I've taken
javadumps and I don't see any thread that is obviously "stuck" anywhere.
Can you share the Java thread dumps?
If locking is involved, implementations are not necessarily fair. This
can lead to such behaviour, especially when locks start to become
overloaded.
Most importantly, if I compare this to a servlet that writes the same
bytes but synchronously (i.e. a "classic" servlet service() method),
then I don't see this aberration.
I can see these long requests in my access log by changing
org.apache.catalina.valves.AccessLogValve to "%h %l %u %t "%r"
%s %b %D", e.g.:
127.0.0.1 - - [04/Sep/2010:18:46:20 -0700] "GET /myapp/ HTTP/1.0" 500
207 10986
127.0.0.1 - - [04/Sep/2010:18:46:22 -0700] "GET /myapp/ HTTP/1.0" 500
207 10428
127.0.0.1 - - [04/Sep/2010:18:46:22 -0700] "GET /myapp/ HTTP/1.0" 500
207 10347
My question is: how do I debug these 500 errors?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org