subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Zender <michael.zen...@mos-tangram.com>
Subject AW: Could not read chunk size: connection was closed by server on Windows 7
Date Thu, 07 Feb 2013 16:34:22 GMT
-----Urspr√ľngliche Nachricht-----
Von: Mark Phippard [mailto:markphip@gmail.com] 
Gesendet: Donnerstag, 7. Februar 2013 15:26
An: Michael Zender
Cc: users@subversion.apache.org
Betreff: Re: Could not read chunk size: connection was closed by server on Windows 7

Sorry for top posting, but see this FAQ:

http://subversion.apache.org/faq.html#secure-connection-truncated

It is the problem you are having.  The error message just varies
between SSL and plain HTTP but the cause is the same.  The client gets
busy doing something and the server thinks the client has gone away
and it kills the connection.

Are you using a Subversion 1.7 client?  While I do not believe it
eliminates the problem, it does manage the working copy radically
different from SVN 1.6 and I would expect it to be less prone to this
problem.



On Thu, Feb 7, 2013 at 9:18 AM, Michael Zender
<michael.zender@mos-tangram.com> wrote:
> Hello everyone,
>
> a couple of days ago, I configured our apache webserver to serve our
> internal subversion repositories over plain old http. Before that, the
> repositories have only been accessible using https. Everything seemed to
> work pretty smoothly but after a couple of hours I had more and more
> complaints about problems that occurred while working (svn co, svn ls
> -v) with directories containing a large number of files (> 3000).
>
> The error message reported was something like the following:
> svn ls http://<servername>/<repourl>/<repopath> -v
> svn: PROPFIND of '/<repourl>/!svn/bc/<rev>/<repopath>': Could not read
> chunk size: connection was closed by server (http://<servername>)
>
> svn co http://<servername>/<repourl>/<repopath>
> svn: REPORT of '/<repourl>/!svn/vcc/default': Could not read chunk size:
> connection was closed by server (http://<servername>)
> An interesting fact about the checkout is, that the working copy has
> been created and so far I've had no problem with it.
>
> I started investigating and was able to reproduce the problem first in
> the live environment before replicating it on a completely different
> server. The specs are:
> OS: Debian GNU/Linux 6.0.6 (squeeze)
> Webserver: Apache/2.2.16
> Subversion: svn, version 1.6.12 (r955767)
>
> I created a test repository with the following script
> svnadmin create project_Test
> chown www-data:www-data project_Test -R
> svn co file:///var/lib/subversion/project_Test wc_project_Test
> cd wc_project_Test
> mkdir src
> for i in {1..1000}
> do
>         head -c 10K < /dev/urandom > src/testfile$i.dat
> done
> svn add src
> svn ci -m "test commit"
>
> The script creates a new repository "project_Test" containing a src
> directory with 1000 10kB files with random content.
>
> And made it available in via apache using the following VirtualHost
> configuration:
>
> <VirtualHost *:80>
>         ServerName svntest
>
>         <Location /svn>
>                 DAV svn
>                 SVNParentPath /var/lib/subversion/
>                 SVNListParentPath On
>         </Location>
> </VirtualHost>
>
> With this setup I was able to reproduce the checkout problem. I
> increased the number of files in the directory to up to 4500 but as of
> now, I've not been able to reproduce the svn ls -v problem.
>
> I did a lot of analysis and my conclusion is, that the problems only
> occur on Windows 7 using any client software we have in use (Eclipse
> integrated client, TortoiseSVN, sv command line client). On WindowsXP
> as well as on Linux, there's no problem at all working with the
> repository using http communication. When I execute the svn co operation
> on a debian system installed on a VirtualBox VM hosted on my Windows 7
> I have the same problem as directly on the Windows 7 client.
>
> I know that there are a lot of emails on this list describing the same
> error message and I spent quite some time to scan through them and to
> follow the links but so far none of them contained a solution for my
> particular problem.
>
> I'll also gladly provide any further information that you find useful to
> further analyze the problem.
>
> Thank you very much in advance for your help!
>
> Michael



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/


Hi Mark,

and thank you for your quick answer!

I tried increasing the Timeout value in the apache configuration (was
300, I doubled it to test this to 600) but that did not resolve the
problem.

The checkout on my Windows 7 client takes about 21 seconds (TortoiseSVN
shows this summary, when the checkout is complete). On the Windows XP
box (where the checkout does not produce any error message), the whole
process takes about 50 seconds.

But you are right about the differences between the two mentioned
subversion version (1.6 and 1.7) and how they manage working copy
metadata. Although I think in my special case it does not make much
of a difference (basically it's just one directory containing all the
files). I also tried to checkout the same directory using a subversion
command line client v1.7.8 (r1419691) but that also lead to the same
problem. However after adding all the files to the working copy, the
TortoiseSVN status line shows that 0kB/s are transfered for a couple
of seconds (I guess when it's creating the metadata directory) and when
it has finished, the error message shows up. As I mentioned in my
previous email the error message also shows up during svn ls -v
operations and I recently tried a svn export which also shows this
behavior. Both of these operations do not create any metadata
directories.

I can also observe this behavior in a project that does not suffer
from the "huge number of files in a single directory" problem. The
project in question has only ~380 files in total with not more than
40-50 in a single directory.

As I mentioned in my previous email I don't have any problems at all,
when I do the same operations using https on the same server.

So again thank you for your help but I hope that maybe someone else has
any idea how I can resolve my problem.

Michael

Mime
View raw message