tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <christopher.d.schu...@comcast.net>
Subject ChannelSocket.read -- always runnable?
Date Sat, 03 Apr 2004 19:54:07 GMT
All,
I'm currently profiling my app running on:

RH Linux 9 / kernel 2.4.20-8
Sun JDK 1.4.2
Tomcat 4.1.29

I'm using Borland's OptimizeIt v4.2 (a bit old, but hey! it's 
expensive!). Technically, I'm running the host on my server (on Linux) 
and the OptimizeIt profiling client on a separate windoze box and 
attaching to the process over the network. It's really irrelevant, but 
often people ask about these things.

When I do a "CPU profile" (really a "what are threads doing" profile) 
during a test where I just make requests as fast as possible, one at a 
time, I'm seeing that most of the time spent by runnable 
(RequestProcessor) threads is in this method:

java.net.SocketInputStream.read()

which gets called by org.apache.jk.common.ChannelSocket.read.

I assume that this is just the Java part of the JK connector sitting 
there waiting for a connection from Apache.

My question is this: why is it runnable? A VM thread dump says that 
they're *all* runnable, instead of sleeping, waiting for data. Is this 
just the way that Java does its sockets? I don't know a ton about the 
Java socket and I/O implementations, but I didn't think that it did a 
spin-wait on stream reading (rather than a blocking read, which would... 
well, block).

Anyhow, it makes the thread profile look very weird, because all of the 
threads are runnable all of the time. Makes it tough to find out which 
threads are actually doing any work :(

It this behavior consistent across Java versions? Are different socket 
implementations used with different connectors? It would be nice if 
fewer threads were runnable when they're really not doing anything.

If someone can give me a good reason for these threads being runnable, 
I'd love to hear it.

Thanks,
-chris

Mime
View raw message