Hi all
I'm investigating a potential problem that I'm having with tomcat 6.0.x
(head of the svn tree).
I have written a fileserver servlet. This servlet works mostly fine with
the NIO connector, except for problems with Sun's DirectBuffer
implementation but that's another story.
The issue I'm having is with the APR connector. Firstly I'll describe
the sequence of events from my client and servlet perspective:
client requests file
servlet gets COMET begin event, parses the request and sets the sendfile
attributes on the request. It also sets the status to 200 and sets
content length, mime type. Then it returns.
client receives file (hopefully ;-)
This works fine in the small. Here's what I'm seeing inside the tomcat
code. I was clued into this by not being able to find my socket (being
kept alive) because all of the pollers were on a "wait" call, rather
than on a "poll" call.
It appears that once the sendfile thread is done it hands the socket off
to a worker, presumably to check if there is another request that has
been received on that socket and can immediately be acted upon. The
issue that I'm having is in Http11AprProcessor line 810. There is a call :
if (!inputBuffer.parseRequestLine(keptAlive)) {
// This means that no data is available right now
// (long keepalive), so that the processor should be
recycled
// and the method should return true
openSocket = true;
// Add the socket to the poller
endpoint.getPoller().add(socket);
break;
}
request.setStartTime(System.currentTimeMillis());
keptAlive = true;
Unfortunately at this time keptAlive is false and this call to
inputBuffer blocks awaiting the next request from the client. I think
that something else is needed here but I'm still learning about the
intent of the code. My suspicion at this point is to ensure that
parseRequestLine is passed true if this worker was handed a socket
following a sendfile request. In this way if there's a following request
that we already have we can work on it, otherwise it goes back to the
poller, where it belongs. Currently if I have 50 clients all having
received a file using sendfile I now have 50 worker threads all blocking
on this line which kind of defeats the purpose of using sendfile.
Is anyone on the list familiar with this area of the code? Does my
reading of this problem seem sound?
Thanks
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
