Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4311FF70.3020101@sharp.fm>
Date: Sun, 28 Aug 2005 20:16:16 +0200
From: Graham Leggett <minfrin@sharp.fm>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
MIME-Version: 1.0
To: dev@httpd.apache.org
Cc: colm@stdlib.net
Subject: Re: [PATCH] mod_disk_cache deterministic tempfiles
References: <BF290A20.1AFF%Brian.Akins@turner.com> <430398AA.2040609@sharp.fm>
 <43039A71.3080803@turner.com> <20050817202905.GA2131@stdlib.net>
 <90B3DD1F144DFDA5DB24334E@st-augustin.ics.uci.edu>
In-Reply-To: <90B3DD1F144DFDA5DB24334E@st-augustin.ics.uci.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Justin Erenkrantz wrote:

>> For a disk cache it would be tricky to discern between a cached file
>> that is half there due to a sudden httpd exit, and a cached file that is
>> half there because a proxy or CGI backend is blocking.

> Exactly.  This is why I've avoided this functionality.  I don't think it 
> can be implemented effectively or efficiently.

I don't think this is a problem that needs complex error handling at all.

In the current situation, if the backend stalls, one frontend client 
will stall. If the in flight cache object is shared, then if the backend 
stalls, more than one frontend client will stall. This is a lesser evil 
than the current behaviour, where thundering herd hits the backend every 
time a resource expires, which in the case of typical news sites, is 
once every sixty seconds.

In both cases, at least one client will eventually get impatient and 
force reload that particular resource. This will invalidate the in 
flight object, and the cache process is retried again.

If the proxy gets impatient and times out the backend, it will 
invalidate the in flight object, and signal to the frontend to close the 
connections. The clients will simply try refetch the object, something 
they would have to do anyway.

> I absolutely dislike the idea of stalling a request because another 
> worker/thread *might* be fetching it.  We should never purposely stall a 
> request because another worker *might* have a request outstanding.

In this case it's not "might", it's "almost always". Any connection 
already faces the very small possiblity that it might hang. That very 
small possiblity increasing in chance by a few simultaneous connections 
is still a minimal risk than the certainty of thundering herd.

Regards,
Graham
--