[Csync2] Syntax error on lock-timeout

[Lars Ellenberg]

On Sun, May 26, 2013 at 07:55:49PM -0700, Gary E. Miller wrote:
> Yo Francisco!
> 
> On Sun, 26 May 2013 12:23:10 -0400
> Francisco Reyes <lists at natserv.net> wrote:
> 
> > On 05/26/2013 02:41 AM, Gary E. Miller wrote:
> > >> And got an error:
> > >> Database backend is exceedingly busy => Terminating (requesting
> > >> retry).
> > >
> > > What you are seeing is a timeout trying to get the lock.  I've had
> > > that problem in spades.  Someone posted a patch to improve that
> > > which works for me, but it has not been accepted yet.
> > 
> > Thanks for the info Gary. I Tried a bit later and did not get the
> > error again. However, I wonder why I got the error in the first
> > place. I am not even putting this in cron yet. Running it manually
> > for testing so there wasn't another instance running.
> 
> Dunno, but I do find that I end up with more csync2 instances running than 
> I expect.
> 
> >  > Check the email archives for it.
> > 
> > Will try searching the mailing list. I did search on the web and that
> > is how I found about the lock-timeout parameter.
> > 
> > How about the lock-timeout parameter? Shouldn't that help? Any idea
> > on the correct syntax for it?
> 
> That idea camse and went before I started using csync2.  It seems
> to have been gone away.

The "lock-timeout" parameter is in the 2.x sources only.

> > Is there a list somewhere of what is new in the coming version?

Sorry, no comprehensive changelog. Try the git log.
A few bug or compat fixes, I guess, but mainly restructuring the code
to be able to use not only sqlite, but also mysql or pgsql as backend.

> > I saw it is in RC2. Is it stable yet for production?

I sure hope so.

Note that I put that "lock-timeout" patch in there in 2009,
so if you feel more comfortable with going with "the latest before
all the changes", rather with current git:

The latest "old stable" commit would probably be this one
from 2010-07-27
http://git.linbit.com/gitweb.cgi?p=csync2.git;a=commit;h=2323463523b08a0995170e9a1f9777881deb82e7
(also tagged with "last-subversion-commit").
It already knows about the lock-timeout.

> No clue, if it does not have Chuck Handshy's patch we have issues with 1.34,
> otherwise my results have been good.

The timeout parameter is "better" than that patch in that the patch
hardcodes the timeout, but the parameter makes it configurable.

The patch has one "advantage" still, it retries every 250ms,
where the current source code still tries only once per second.
If you say that makes sense, we can easily add yet an other config
parameter for that, or just hardcode it to 250ms as well.

I've never run into this problem myself, but then we usually don't use
it in a way that operates on millions of files at once...

	Lars