> -----Ursprüngliche Nachricht----- > Von: Michael Zender [mailto:michael.zen...@mos-tangram.com] > Gesendet: Donnerstag, 7. Februar 2013 17:34 > An: users@subversion.apache.org > Betreff: AW: Could not read chunk size: connection was closed by > server on Windows 7 > > -----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
Hello everyone, I finally solved my problem and wanted to share my solution with you. It turned out, that Kaspersky Endpoint Security 8 and its Web-Anti-Virus feature in particular were causing this problem to show up. We solved it by defining a rule that excludes our subversion servers from the Web-Anti-Virus service. The Windows XP still had Kaspersky 6 installed which does not have the Web-Anti-Virus feature. I still don't know what exactly the problem is because in my opinion, the anti virus software should act in a completely transparent manner but anyways, it's working now, so I don't bother any more! Thanks again to Mark for his reply, it definitely made me investigate in the right direction. Have a nice weekend everyone! Michael
