[Http-crcsync] Apache proxy CRCsync & mozilla gsoc project?

Martin Langhoff martin.langhoff at gmail.com
Thu Apr 2 04:53:54 EDT 2009


On Thu, Apr 2, 2009 at 10:39 AM, WULMS Alexander <Alex.WULMS at swift.com> wrote:
> different for each request. Even if the get request handling at the server side is implemented idem-potent as per http convention,
> the page might still change on a next request due to server-side background activities.

Correct.

I think the race conditions in your (correct, and very likely!)
scenario can be addressed if the processes update files atomically -
so instead of updating the file in place

 - copy the file to a tmpfile
 - modify the tmpfile in-place
 - fsync(tmpfile) and rename/mv the file into  place

In high-concurrency scenarios, we'll be creating many many files and
repacing them immediately. This is pointless IO -- it will make sense
to have a rule to not update the cache if the cache file is less than
X seconds old, with a default of perhaps 60.

In that case, if there is a collision, we can consider the cached file
we are basing the transaction on as part of the problem. So stat() the
file ot check that t hasn't been updated, and if it's still the old
file, rm it.

The rm is racey. but it is a benign race -- we lose a cached file,
nothing bad happens. If a process has it open (reading from it for
another proxy request) , POSIX semantics keep the file until it is
closed.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


More information about the Http-crcsync mailing list