On Mon, 14 Jul 2003, Justin Erenkrantz wrote:
> --On Monday, July 14, 2003 14:10:02 -0500 Ben Collins-Sussman
> <sussman@collab.net> wrote:
>
> > Sure enough, if you set "http-compression = no" in the [global]
> > section of your client's ~/.subversion/servers file, all the timeout
> > problems vanish. This is the official workaround, until we fix apache.
> >
> > gstein says that jerenkrantz is now going to have to fix mod_deflate. :-)
>
> The correct solution, IMHO, is to have mod_dav pass flush buckets down the
> output chain by using ap_rflush or sending down its own flush buckets via
> ap_filter_flush. The function that looks like it definitely needs the
> flush is dav_send_one_response. Not sure if that'll catch all of your
> cases or not - it may need to be added other places.
>
> mod_dav knows when it is appropriate to flush the content. mod_deflate
> doesn't attempt to make any determiniations on its own when to flush.
> Mainly because doing the flush may be expensive in zlib - we don't want to
> do it on every deflate() call. That logic is best placed in the handler -
> mod_dav. And, for the most part, mod_dav does create flush buckets - it
> just seems to be missing a few obvious cases. -- justin
Sorry Justin, but that is bogus. The whole point of the handler/filter
flow is that the handler shouldn't have to control stuff like this. The
filter needs to realize that it has buffered far too much data and flush
it appropriately. Take a look at the core_output_filter. It doesn't wait
for a FLUSH bucket from the handler. It notices that it has buffered 8k
of data and takes the initaitive to get it to the network ASAP. If you
push this up to the handler then every handler will need special logic to
deal with every filter.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 14 21:54:27 2003