Updating /seen from concurrent sessions
leg+ at andrew.cmu.edu
Tue Nov 26 13:38:31 EST 2002
To keep everyone up to date (Andrew already knows this):
I was wrong, everyone else was right. The flat backend has a bug in it
that if a given seen file frequently reuses the same inode (as will
happen frequently on lightly loaded systems) you run into this strange
behavior with seen state between sessions.
I believe I've fixed this bug in CVS (did it a few days ago, actually)
and it'll be in the next release.
My apologies for my disbelief,
Date: Fri, 15 Nov 2002 10:08:52 -0500
From: Lawrence Greenfield <leg+ at andrew.cmu.edu>
--On Friday, November 15, 2002 8:49 PM +1100 Andrew McNamara
<andrewm at object-craft.com.au> wrote:
> I suspect there is a bug in the flat-file seen implementation. Each
> process opens the seen file and holds this file descriptor open. Then one
> process wants to update the file. It does this by writing a new file,
> and renaming it into place. But all the other processes still have the
> now unlinked and out of date copy open.
I'm still very dubious about this explanation. If you examine cyrusdb_flat,
you'll see that "fetch()" calls "starttxn_or_refetch()", which either locks
the file and makes sure we have the latest version or (if it's in a
non-transactional read) makes sure it's reasonably up to date.
More information about the Info-cyrus