svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod

> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett 
> Gesendet: Mittwoch, 25. Oktober 2006 22:21
> An: devhttpd.apache.org
> Betreff: Re: svn commit: r467655 - in
/httpd/httpd/trunk: 
> CHANGES docs/manual/mod/mod_cache.xml 
> modules/cache/mod_cache.c modules/cache/mod_cache.h
> 

> 
> I managed to solve this problem last night.
> 
> Took a while and a lot of digging to figure it out, but
in 
> the end it is 
> relatively simple.
> 
> The ap_core_output_filter helps us out:
> 
>      /* Scan through the brigade and decide whether to 
> attempt a write,
>       * based on the following rules:
>       *
>       *  1) The new_bb is null: Do a nonblocking write
of as much as
>       *     possible: do a nonblocking write of as much
data 
> as possible,
>       *     then save the rest in ctx->buffered_bb. 
(If 
> new_bb == NULL,
>       *     it probably means that the MPM is doing
asynchronous write
>       *     completion and has just determined that
this connection
>       *     is writable.)
>       *
>      [snip]
> 

AFAIK this is only true on trunk due to Brians async write
patches there.
They have not been backported to 2.2.x and I think they are
unlikely to
get backported. Thus this solution for mod_disk_cache only
solves
the problem on trunk. This not necessarily bad, but I guess
people should
be aware of it.

Regards

Rüdiger