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
--
