[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Flushes in httpd

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-07-15 22:48:39 CEST

Hah! And we're all idiots, too. :-)

ap_filter_flush() doesn't actually generate a FLUSH bucket. It is simply a
cover for ap_pass_brigade() with a prototype and an assumption about its
void* parameter to make it useful to pass into the apr_brigade_* writing

IOW, the ap_filter_flush -> ap_pass_brigade change will have no material
impact except to save a function call.

I'll be updating some headers and whatnot in httpd to clarify this, and I'll
go ahead and remove that overhead. But the underlying point still stands:
there is no way that mod_deflate should continue to buffer *ENTIRE*
responses. That is simple insanity... (not to mention the cause of the
timeouts people have been seeing, and quite probably the large working sets
that people have seen for httpd)


On Tue, Jul 15, 2003 at 10:59:53AM -0700, Greg Stein wrote:
> Right. mod_dav's use of ap_filter_flush() is wrong. It should be using
> ap_pass_brigade() to pass the brigade contents down the filter stack. As it
> stands right now, we are flushing the content to the network via a FLUSH
> bucket, returning from the handler, and Apache is then sending a brigade
> with an EOS bucket. If we just pass our remaining brigade contents (before
> function return in the two places where flush is called), then the EOS will
> ensure the response is flushed to the network.
> (in fact, I'll make this ap_filter_flush -> ap_pass_brigade change later
> today... it is the right thing to do)

Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 22:42:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.