Bill Stoddard wrote:
> 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.
In the original design (not sure what it is now) the memory cache code
set aside a whole lot of brigades, and each brigade was simply added to
the cached brigade set.
In order to ensure there was enough memory, the original design limited
memory caching to requests with a Content-Length header, ie a
predetermined length. Thinking about this some more this isn't even
necessary, as the cache could simply keep adding brigades to the cache,
and should the length of the brigades cached so far exceed a certain
value, it could simply toss away the entire set aside set of brigades
and remove the cache_in filter, thus ditching the cache attempt.
The only problem with this is with requests that are "shadowing" this
request. ie a subsequent request that has requested a resource half in
the cache already and still being fetched. If the leading thread ditched
the caching attempt, the shadowing threads might get confused as the
data they are sending just got ripped out from under them. What might be
possible is for some intelligence to be built in to only throw away
buckets that are not due to be shadowed. All in all though it is still
easier to mandate that only objects with a predetermined length can be
memory cached.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED]
"There's a moon
over Bourbon Street
tonight..."
