55

When updating from subversion repository using tortoise svn client I get error looking like that:

Could not read chunk size: An existing connection was forcibly closed by the remote host.

It doesn't prevent me from updating, just interrupts update process, so that I have to repeat update several times, before it is complete.

What can cause such behaviour and how to fix it?

Denis
  • 567
  • 1
  • 5
  • 7
  • 4
    +1 same here. The annoying thing is that the client error message blames the server, but the apache server logs don't show any errors at all. – Wim Coenen Apr 21 '09 at 16:07
  • What is your server side set-up? In our case the repository is hosted by an apache webserver on a windows system. – Wim Coenen Apr 22 '09 at 12:14

13 Answers13

15

I was getting the "Could not read chunk size" message from clients on several machines.

The key to figuring it out was this error in the Apache error log:

[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response.  [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision  [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files  [500, #24]

The Apache process handling the svn operation was running out of file descriptors. On my Ubuntu server, I fixed it by editing /etc/security/limits.conf and adding this at the bottom:

*               hard    nofile          5000
*               soft    nofile          5000

Which increases the file descriptor limit from 1024 to 5000. Then I logged in on a fresh shell and confirmed that the limit got increased via ulimit -n. Then restarted Apache.

Lachlan
  • 3,626
  • 2
  • 23
  • 29
11

I just got the 'could not read chunk size' error AND FOUND A SOLUTION -- at least for one scenario.

First, my configuration...

SERVER: CollabNet Subversion Edge Server 2.0.0-2190.74 (Subversion binaries 1.6.17-2190.74) running on Windows Server 2003 32-bit.

CLIENT: TortoiseSVN 1.6.16, Build 21511 - 32-Bit (Subversion 1.6.17) running on Windows XP Pro 32-bit with SP3.

Steps to reproduce...

I got this error after right-click-dragging a versioned subfolder into another versioned subfolder within my local working copy folder and then choosing 'SVN Copy versioned item(s) here' (this is a TortoiseSVN context menu command in Windows Explorer when right-dragging folders). The subfolder contained one ANSI-encoded text file, MANIFEST.MF, which I believe I did not modify (my Subversion configuration does not include a mime type for .MF files). I subsequently committed the newly copied subfolder. Later, anytime I tried to update my Subversion local working copy folders on this PC, I got the chunk size error.

Work-around...

I resolved this by restarting my Subversion/Apache service (which in and of itself did not help and may not have been necessary), then deleting the newly added subfolder from my local working copy folder (it had already made it to the repo, so I wasn't going to lose anything), and THEN performing an Update, which succeeded without the chunk size error and re-fetched the subfolder I just deleted.

In my case, I had copied TWO versioned subfolders this way, and I could not successfully update the root of my local working copy folder until I had deleted BOTH of these new subfolders.

Follow-up...

I assume this is a bug in Subversion server and/or TortoiseSVN client, but I do not have the debugging skills to make that determination. I'll report my findings in the TortoiseSVN Issue Tracker and see where that goes.

MikeOnline
  • 623
  • 8
  • 15
10

I just had this happen to me, and it was not a server issue; my working copy got corrupted (by me, incidentally).

hoffmanc
  • 572
  • 7
  • 16
  • 3
    @Chris Since svn follows a remote repository model, I simply checked out another working copy in another location, and applied a patch of my changes to it. – hoffmanc Jun 23 '11 at 12:17
  • I got something similar after moving a DNS name from one server to another (both had a repo with the same name) and a client still had working copy files from the old repo and did an svn import into the new repo. So, what we might call 'working copy problems' can definitely cause the "chunk size error". – Matthew Skelton Nov 20 '12 at 18:46
  • A better solution is to run cleanup of the working copy of the folder that got corrupted and then run update again. – Nux Nov 30 '12 at 18:56
  • 3
    @Nux I have a very low success rate with the cleanup command. – hoffmanc Dec 02 '12 at 12:44
  • You might need to check all options of cleanup (including reverting all changes). It works every time for me. And for big repos this occur quite often for me (at least for 1.6 server and 1.7 client). – Nux Dec 03 '12 at 15:40
7

The problem and (some other) disappeared after turning off client-side antivirus.

I'm using Ubuntu server with subversion 1.7.4 via Apache.

vrogach
  • 538
  • 12
  • 16
3

Check the apache error log, there should be an error logged in there with an error number. That number will help finding out why the connection was dropped.

If there's nothing in the error log, check your virus scanner/firewall settings: some of those tools will drop a connection if they think the transferred data is dangerous.

Stefan
  • 42,026
  • 10
  • 73
  • 116
2

For us the problem was an a timeout on Apache. The update was taking about 15 minutes, but Apache timed out after 10 minutes, causing our SVN server to give the error you see. The final solution was to increase the timeout setting for Apache. We use VisualSVN server - for detailed instructions on how to change this setting, look here: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html

CodeThug
  • 2,836
  • 1
  • 17
  • 16
  • This was also the solution to my problem. Our client was git svn, the server Subversion Edge under Windows 2008 R2, and the solution to add the "Timeout 1800" to csvn\data\conf\httpd.conf and restart the Collabnet Apache service. This link http://subversion.apache.org/faq.html#secure-connection-truncated also gives a clue. – willw Dec 05 '14 at 16:42
1

VisualSVN 2.5.8: Had the same error, next steps helped me to fix this error:

On the server:

  1. Deleted on the server problematic folder;
  2. Restart VisualSVN server.

On Workstation:

  1. Update parent folder ;
  2. Add folder and files again ;
  3. Add to SVN ;
  4. Commit.
Eugene Bosikov
  • 790
  • 8
  • 12
1

I changed to an Ubuntu server and we had this same error - across multiple client PC's, OS's, and client versions.

After making sure that both the file limit settings and Apache timeout settings were as suggested.

(See http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ )

I eventually solved the problem by using the apache2-mpm-prefork package rather than the apache2-mpm-worker package.

Simon Hoffe
  • 11
  • 1
1

I was getting this same error message on updates after I renamed a folder and committed. I created a new working directory and didn't receive the error. So, I just moved my changes to the new working directory, committed and blew away the old directory.

So, this error seemed to be caused by my local directory getting corrupted.

0

For us, the workaround was to downgrade the SVN client from 1.8 to 1.7 (command line client that's bundled with TortoiseSVN).

Frank Schmitt
  • 27,865
  • 9
  • 65
  • 100
0

There is another annoying cause for this error message. It could be your router or your router's firmware.

I had recently upgraded my Linksys WRT110's firmware from version 1.0.02 to 1.0.07 and after that, subversion could no longer add new files to the repository. It could only update existing files. Rolling back to 1.0.02 fixed the problem.

Sources:

Basically, anytime the connection is abruptly dropped, you're going to get this error. Could be a configuration error on Apache, like many of you stated. It could also be due to a slow server or overloaded connection, or it could be due to a cheap router, as was in my case.

mrbinky3000
  • 3,505
  • 8
  • 37
  • 52
0

This clearly has many causes, but for me this was fixed by restarting my SVN server (VisualSVNServer 2.5.1). This occurs frequently when doing a full repo checkout on a newly loaded dump.

Derrick
  • 2,374
  • 2
  • 21
  • 32
0

I get that also. Our server is Apache running on Windows. My client is connected with a high speed but somewhat high latency (200ms.) The other part of the puzzle is that I am running windows Vista. Turning autoscaling and rss seems to improve the situation, but does not fix it.

Jeremy White
  • 871
  • 2
  • 7
  • 21