RE: Sync Fail on svn 1.6.9

I have run into the same "first" sync issue again today. This time it was on a commit that involved over 8000 paths. When I gave the sync command myself I got this error output:
Transmitting file data .........<truncated - this really ran for over 6000 polka-dots>............svnsync: REPORT of 'http://serverName/parentDirectory/repoName': Could not read response body: connection was closed by server (http://serverName)

However, today my dump>load>sync method of recovery was successful. I did not see my "second" sync issue involving 'fail to get lock' today.

Is there a commit size limitation on syncs? Maybe a best-practice I can warn our SVN users about?

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

Does the race condition have more than one way of expressing itself?

Because it has always appeared the same when I find it. Two commits get out of order and this causes svnsync to quit. The rev-prop data is not synced on the two corrupted revs, and this causes any attempt to sync again to return with an error message asking if anyone has committed directly to the mirror. After I remove the corrupt /revs and /revprops files - and edit a couple of the /db files, the sync operation can run again.

This race condition is rare - the fix is a little tricky - but quick enough to be tolerable. Is there any corruption possible from the race condition that I am not yet aware of?

> I'd recommend to make your hook scripts use a common lockfile to avoid this situation.

When I looked at this method before - it seemed undesirable for some reason I don't recall. I will look into it again.

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

Unfortunately, running sync from a cronjob is not an acceptable option here.

Thanks,
Krista

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This message is for the named person's use only. This communication is for
informational purposes only and has been obtained from sources believed to
be reliable, but it is not necessarily complete and its accuracy cannot be
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.

Securities products and services provided to Canadian investors are offered
by ITG Canada Corp. (member CIPF and IIROC - Investment Industry Regulatory
Organization of Canada), an affiliate of Investment
Technology Group, Inc.

ITG Inc. and/or its affiliates reserves the right to monitor and archive
all electronic communications through its network.

ITG Inc. Member FINRA, SIPC
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Received on 2010-04-17 02:19:54 CEST