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
