httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF EITO <ruediger.pl...@vodafone.com>
Subject 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
Date Thu, 26 Oct 2006 08:28:14 GMT


> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett 
> Gesendet: Mittwoch, 25. Oktober 2006 22:21
> An: dev@httpd.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



Mime
View raw message