Potential problem with COMET & sendfile

[Alex Barclay]

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]

Re: Potential problem with COMET & sendfile

[Alex Barclay]

Remy Maucherat wrote:

On Tue, 2008-05-20 at 15:40 -0700, Alex Barclay wrote:
  
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.



No need to write a novel to expose a simple problem. BTW, Comet +
sendfile is not tested at all, so it is possible it won't work right.
The issue you're seeing is that at the end of sendfile it does a
processSocket(state.socket) rather than add back to the poller (which is
the normal procedure at the end of processing many other requests).

  

It's getting tested now ;-)

I've found a couple of bugs so far. I'll have patches by the end of the 
week.


In our application we're using this for our main file server, sending 
files up to 10MB in length, so this is showing up lots of interesting 
behavior.


Alex.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Potential problem with COMET & sendfile

[Alex Barclay]

Filip Hanik - Dev Lists wrote:

I don't see any use case for Comet+sendfile make sense.

but if you do it, you should

...
set your sendfile stuff
call CometEvent.close()
.

ie, the event shouldn't be cometized when doing sendfile, it makes 
zero sense since when the file is sent, the HTTP request is over.
You're right. In this case because I'm dealing with the request in the 
begin event and doing a sendfile the request won't be cometized. The 
other case is where the verb is a put or a post at which point it will 
be cometized. Yes I am doing a close on the event, it breaks really 
horribly if you don't do this.


Alex.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]