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
signature.asc
Description: OpenPGP digital signature
