You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Alex Barclay <al...@planet-barclay.com> on 2008/05/21 00:40:46 UTC
Potential problem with COMET & sendfile
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
Re: Potential problem with COMET & sendfile
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Alex Barclay wrote:
> 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.
yes, even then you shouldn't do this using comet, just a regular
servlet, there is no reason for doing sendfile using comet, it makes
little sense, and I don't think it makes sense for us to support it either
Filip
>
> Alex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Potential problem with COMET & sendfile
Posted by Alex Barclay <al...@planet-barclay.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Potential problem with COMET & sendfile
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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.
Filip
Alex Barclay wrote:
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Potential problem with COMET & sendfile
Posted by Alex Barclay <al...@planet-barclay.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Potential problem with COMET & sendfile
Posted by Remy Maucherat <re...@apache.org>.
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).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org