--On August 18, 2005 9:24:57 AM +0100 Colm MacCarthaigh <[EMAIL PROTECTED]>
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
