On Thu, Apr 15, 2010 at 07:10:00PM -0400, Andersen, Krista wrote:
> Do you know what SVN does now to detect and remove stale sync locks? Can this be related? Is it possible my first sync issue is from timing-out? Or perhaps it only appears to timeout from my command line client's point of view - while the sync still occurs in the background? (Which might explain the appearance of the second issue?) Or perhaps the second sync issue is related to SVN's attempt to recover from stale sync lock? How is that handled? Is the lock simply removed? Or does it repeatedly attempt to finish the sync as well?
>
There was indeed a change for svnsync in 1.6.9:
http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
Version 1.6.9
[...]
* fixed: svnsync leaves stale sync-locks on mirrors (r884842)
This fix prevents svnsync from creating stale locks due to a bug
in the locking algorithm. The bug was rarely triggered, because
it only occurred if svnsync could not acquire the lock in 9 out of
10 attempts and succeeded during the 10th attempt. It would acquire the
lock and leave the lock in place, but think that it didn't get the
lock (there was a problem with the ordering of set and test during
the last lock attempt).
I am not sure if this is related to what you are seeing, however.
svnsync locks do not clean themselves up. svnsync has no mechanism
to recover from stale locks. So I am not sure how your problem was
suddenly fixed. My best guess is that because you removed the lock
manually and repaired the svnsync meta data, a subsequent commit
triggered another sync which may have taken a while but eventually
brought the slave up-to-date again.
Note that running svnsync from the post-commit hook without additional
external locking provisions is a bad idea because of the known race
condition. A huge commit can cause a sync to last long, and commits
happening while that sync is in progress will be piling up further sync
jobs, triggering a "thundering herd" effect after the long sync finishes
(or aborts). A bunch of svnsync processes might try to lock the repository
concurrently, possibly triggering the race condition which causes svnsync
meta data to be out-of-sync with the slave repository's state.
I'd recommend to make your hook scripts use a common lockfile to avoid
this situation. If a revision is not mirrored by the corresponding
post-commit hook, subsequent commits will cause it to be mirrored.
You could also run a cronjob (using the same lockfile) which tries
to sync outstanding commits in case syncs triggered by the post-commit
hook were starved during the sync of a large commit.
> Where is the best place to find documentation about how the sync-lock is handled in 1.6.9 ?
I'm afraid the best place is in the code:
http://svn.apache.org/repos/asf/subversion/tags/1.6.9/subversion/svnsync/main.c
See the get_lock() and with_locked() functions.
(Note again that svnsync isn't using a proper lock because setting
and getting a revision property is not an atomic set-and-test primitive.
So usage of the word "lock" is misleading.)
Stefan
Received on 2010-04-16 02:19:19 CEST