httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] mod_disk_cache deterministic tempfiles
Date Thu, 18 Aug 2005 17:07:29 GMT
--On August 18, 2005 9:24:57 AM +0100 Colm MacCarthaigh <colm@stdlib.net> 
wrote:

> On Wed, Aug 17, 2005 at 03:17:41PM -0700, Justin Erenkrantz wrote:
>> > Content definitely should not be served from the cache after it has
>> > expired imo. However I think an approach like;
>> >
>> >    if((now + interval) > expired) {
>> >        if(!stat(tmpfile)) {
>> >	    update_cache_from_backend();
>> >	}
>> >    }
>> >
>> > ie "revalidate the cache content after N-seconds before it is due to be
>> > expired" would have the same effect, but avoid serving stale content.
>> >
>> > Does that make sense?
>>
>> Um, isn't that what we already do?  -- justin
>
> No :-) Right now, once the cache entity stops being considered fresh,
> each worker that gets a request will fetch it, store it to their own
> tmpfile and race to be first to rename it.
>
> With the above approach, there could be some kind of user-configurable
> interval before expiry, say 10 minutes in this example. So, the first
> request that happens within that 10 minute interval would re-validate
> the cache entity.
>
> If it doesn't need to be fetched and gets a not-modified, we just
> "touch" the cache entity and go on our merry way.
>
> If it does need to be fetched then a deterministic tmpfile ensures that
> no other worker bothers to fetch it at the same time, they can serve
> from the cache in the meantime - which still hasn't expired.
>
> If after the 10 minutes the content still isn't there, the user should
> have set a better value for "interval", and we've no choice but to start
> fetching the content per-request until something writes a cache file.

Okay.  I see what you mean now.

If the interval is configurable via a directive, then yes that makes sense. 
This could be done independently of deterministic tempfiles.  (I hope this 
means you volunteer to write the patch!)

However, using deterministic tempfiles means that there's a possibility of a 
'deadlock' - in that a response will never be updated because of a stuck or 
dead process.  I've not seen a feasible strategy to resolve this issue.

In the case of fetching before expiration, the 'lock' can be 'advisory' - 
after expiration, it can fall back to the current case.  -- justin


Mime
View raw message