Re: Can't read length line in file (again).

[John Szakmeister <jo...@szakmeister.net>]

[snip]
> The user in question seems to have some random network issues as well I
> think.  She connects over the VPN on a cable modem.  Occasionally when
> commiting she will get an error message about the connection being killed
> (don't have the exact message, I can get it if it will help), or it will
> 'stall' for a very long time.  
> 
> The commits that have caused the corruption, however, went 'fine' from her
> standpoint.  Though she did have at least one 'failed' attempt before it I
> think (though not immediately).

I don't think this is connection-related at all.  There are checksums occurring over the wire, so bad data would get thrown out before it attempted to finalize the revision.

> 
> I wrote a script to create ramdom binary data in a file 2-5 meg in size,
> and commit it.  I ran this script over night from my own VPN connection
> (just commiting the same file over and over again with random changes).  It
> ran flawlessly...

I've done similar things, with small and large files on a multiprocessor machine.  In fact, I believe I ran it for about 40 hours straight, and got nothing. :-(

> 
> I'm going to have her try to do some commits to a copy of the repository to
> see if we can eventually reproduce the issue there (so it doesn't effect
> other developers).  I had her do a few already and they went fine (save for
> one that got the connection error).
> 
> 
> With two repository corruptions in a couple weeks some folks are starting
> to lose a bit of faith in SVN here.  I'm very interested in finding this
> problem.  I can't provide my repository, but I can do testing on a copy of
> the repository itself.  I'm just not sure where to start.  I suspect her
> 'choppy' internet connection may be at the heart of this, but I'm not sure
> how to fake that (at home I'm behind a Linux router - if anyone knows of a
> way to get it to fake a 'bad' connection that may help).  

One way to avoid this particular issue is to switch to the BDB backend.  Given your configuration, there should be little worry of it wedging.  Just be careful when upgrading as we've seen some issues with BDB and their upgrade process.  In general, it's not a big concern though.

> Anybody have any ideas on how I can reproduce this?  Any test scenarios?
> If more information is needed I will try to provide it. 

Have you tried dumping the repository to the version the repository was at when your user was committing, and trying to commit the file?

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Can't read length line in file (again).

[Andrew MacKenzie <am...@edespot.com>]

> > The commits that have caused the corruption, however, went 'fine' from her
> > standpoint.  Though she did have at least one 'failed' attempt before it I
> > think (though not immediately).
> I don't think this is connection-related at all.  There are checksums
> occurring over the wire, so bad data would get thrown out before it
> attempted to finalize the revision.
Hrm.  That seems to be the only thing this user has 'different' about her
though.  There's lots of other folks using SVN and nobody has managed to
corrupt a repo, and she's done it twice!


> > I wrote a script to create ramdom binary data in a file 2-5 meg in size,
> > and commit it.  I ran this script over night from my own VPN connection
> > (just commiting the same file over and over again with random changes).  It
> > ran flawlessly...
> I've done similar things, with small and large files on a multiprocessor
> machine.  In fact, I believe I ran it for about 40 hours straight, and
> got nothing. :-(
I'm going to try again this time with my router dropping packets,
adding delay, etc. (found a program called 'tc' that can do such things).
It'll probably be fine, but I'll give it a go anyway (at least proving to
myself that network issues aren't the problem).

Possibly it's being triggered by Tortoise somehow?  My script ran with the
svn.exe command line client.  I'll try more tests with TSVN...

> One way to avoid this particular issue is to switch to the BDB backend.
> Given your configuration, there should be little worry of it wedging.
> Just be careful when upgrading as we've seen some issues with BDB and
> their upgrade process.  In general, it's not a big concern though.
There is push-back on that one, given that BDB doesn't seem terribly
well supported anymore...  I'll suggest it to others if we hit this again
though.

> > Anybody have any ideas on how I can reproduce this?  Any test scenarios?
> > If more information is needed I will try to provide it. 
> Have you tried dumping the repository to the version the repository was
> at when your user was committing, and trying to commit the file?
Yes.  I actually did that as part of the restore process.  When I commited
it it went though fine.


It seems to me that this particular user has something 'special' about
either her setup, configuration, or methods that makes her more likely to
have an issue.  I'm trying to get her to reproduce it in an 'unused'
repository.  The only thing that leaps to mind is her network issues. 

Until I can find something the folks on this project are nervous about
letting her commit anything...

-- 
// Andrew MacKenzie  |  http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// In computing, invariants are ephemeral.
//     - Alan Perlis