httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject RE: [PATCH] mod_cache: support caching of streamed responses
Date Mon, 02 Sep 2002 12:41:48 GMT
> This patch allows mod_cache to cache a response that isn't
> all contained in the first brigade sent through cache_in_filter().
> (This scenario happens, for example, with reverse-proxy requests,
> CGIs, and various app server connectors.)
> Can someone familiar with the caching code please scrutinize
> the patch and send comments?  There's one known problem with
> the code (details below), but it's otherwise ready for review.
> The way it works is:
>   * If the first call to cache_in_filter() includes an EOS,
>     the operation is unchanged: put the response in the cache (
>     assuming it meets all the other cacheability criteria) and
>     pass the brigade to the next filter.
>   * If the brigade passed to cache_in_filter() doesn't have an
>     EOS, though, the filter now makes a copy of the brigade and
>     passes the original on to the next filter.  In subsequent
>     calls, cache_in_filter() continues buffering up copies of
>     the buckets while streaming the response on to the next
>     filter in the chain.  Once it finally sees an EOS, it
>     concatenates the setaside buckets into a single brigade
>     for storage in the cache.  It then streams the last bit
>     of the output to the next filter.
>   * If the response contains any bucket with length==-1 (an
>     unread pipe bucket, for example), the filter doesn't attempt
>     to cache it.  (It's probably possible to add support for
>     this in the future.)
> The one thing that's missing is a check to avoid setting aside
> too much data.  If the total size of the setaside buckets would
> exceed the maximum object size for the cache, cache_in_filter()
> should immediately discard the setaside buckets and give up on
> caching the response.  What's the right way to implement this
> check?  It looks like the max object size is a property of each
> specific cache implementation (mod_mem_cache, mod_disk_cache).
> The first solution that comes to mind is to make each cache
> implementation provide a callback function that says whether
> it's willing to cache an object of size X.  Is there a cleaner
> solution?
> -Brian

Adding a callback/hooks sounds okay.  An additional problem to consider is
when a frequently requested resource does not return an EOS in the firet
brigade and it turns out to be too large for the cache. We need a negative
cache (what else would you call it?) to prevent mod_cache from attempting to
cache the same object over and over. If the object is too large, create a
negative cache entry.  Consult the negative cache when the response is
received to determine if mod_cache should even attempt caching.



View raw message