> -----Ursprüngliche Nachricht-----
> Von: Michael Zender [mailto:michael.zender_at_mos-tangram.com]
> Gesendet: Donnerstag, 7. Februar 2013 17:34
> An: users_at_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:markphip_at_gmail.com]
> Gesendet: Donnerstag, 7. Februar 2013 15:26
> An: Michael Zender
> Cc: users_at_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_at_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
Received on 2013-02-08 16:29:25 CET