-----Ursprüngliche Nachricht----- Von: Mark Phippard [mailto:markp...@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.zen...@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
