I've CC'd the dev@ list in hopes that someone else with more knowledge
of Apache, mod_dav, and mod_dav_svn can help with this.
Ranjit Kenaudekar wrote:
> Hi John,
>
> We ran into same error gain and coincidently with the
> same file "StoryBoard.doc". This happened with
> revision 222. I did a dump with the last good revision
> 221 and recreated the repository.
Ouch. That's not good.
> I have a working repsository now, thanks for the
> 'svnadmin dump'. But this is getting scary.
>
> I will explain to you the sequence of commits that
> happened before this corruption.
>
> (1) I fixed the repository by using the repaired file
> you provided i.e. 94.empty.
>
> (2) 'svnadmin verify/dump' successfull. Everthing
> seemed normal.
>
> (3) I asked stacy to checkin StoryBoard.doc from his
> Windows TortoiseSVN client. The commit was successful.
>
> (4) I saw many commits later on. No problems. I even
> saw new commits for StoryBoard.doc.
>
> (5) Stacy reports he is unable to commit
> StoryBoard.doc . The error he gets on his window is:
> Error PUT of '/svn....StoryBoard.doc':
> Error Could not send request body: An existing
> connection was forcibly closed by the remote
>
> The error reported in the /opt/apache/log/error_log
> file is:
> Could not get next bucket brigade [500, #0]
Interesting. Someone on the dav-dev@ list saw this same error but got
no response. Also, someone on the users@ list saw this error, as well,
but they were running a 'packet shaper' that was dropping packets
depending on the load. Are you running anything of the sort? Is there
any network equipment between the client and server? I've found via
Google that this error is generally caused by the client disconnecting
during the middle of a PUT operation, and mod_dav is sending that error
back.
> Next he deletes the folder that has StoryBoard.doc and
> updates again. Copies the file and commits. This time
> the commit is successful.
>
> (6) After sometime again he modifies the
> StoryBoard.doc and tries to commit and he gets the
> same error as in (5). He tries several times with no
> luck.
>
> (7) He then SCP's the StoryBoard.doc file to the
> server where subversion is hosted (linux box) and
> commits from there successfully using the command line
> svn client.
>
> (8) And the next thing we get is the "Can't read
> length line error captured by 'svnadmin verify'
> through my cron job. I have attached the problem file
> for your perusal.
Interesting. I don't understand how this sequence of events could have
lead to the line length problem. I'm hoping that someone else here on
the dev@ list can help out.
When you copied it up to the server, did you commit using a file:// or
https://?
> (9) This is the exact sequence when it had earlier got
> corrupted.
>
> Though we have a working repository now, I am not very
> confident if we get this type of problem again and
> again.
>
>
> Our Setup:
> We are runing Redhat 9 (2.4.21-32.0.1.ELsmp) on HP DL
> 280 with 2 CPU's ( I will confirm this )
> subversion 1.2.1
> apache 2.0.54 compiled with support for openldap,
> openssl, berkeleydb
>
> These are the options we used to be precise:
> ../configure --prefix=/opt/apache-2.0.54 --enable-so
> --with-ssl=/opt/openssl --enable-ssl --enable-proxy
> --enable-proxy-http --enable-rewrite --enable-cache
> --enable-speling --enable-ldap --with-ldap
> --with-ldap-lib=/opt/openldap/lib
> --with-ldap-include=/opt/openldap/include
> --enable-auth-ldap --enable-disk-cache
> --enable-mem-cache --enable-info --enable-cgi
> --enable-mime-magic --enable-dav
> --with-berkeley-db=/usr --with-dbm=db43
> --with-neon=/usr
I see your version of svn is a bit behind, but I don't think it should
lead to the problems you're seeing.
To those on the dev@ list, any help here would be much appreciated. I
think I've reached the bounds on my knowledge of Subversion (especially
on the Apache side of things) to adequately help debug this problem. :-(
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 21 14:57:04 2005