tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Barclay <a...@planet-barclay.com>
Subject Potential problem with COMET & sendfile
Date Tue, 20 May 2008 22:40:46 GMT
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message