Tuesday, September 7, 2010

SVN Trouble

(If all you want to do is solve the same problem, you only need to add a Timeout 1800 line to your c:\program files\visualsvn server\conf\httpd-custom.conf file and restart Visual SVN server - you can, of course, adjust the number of seconds as you like)

First off, if you are doing any kind of software development and you aren't using source control of some kind, you are missing out big time. I highly recommend source control. I use Visual SVN for the server and Smart SVN for the client, but there are lots of other great options out there. OK, on to the good stuff.

We have purchased licenses for RedGate's SQL Source Control, which allows you to use SQL Manager to check in SQL objects into a SVN repository. Very cool. I had been using this for a short while, and I soon saw this error when trying to scan for changes:

Could not read chunk Size: secure connection truncated
It mentioned a 'secure connection', and so I figured that SSL could be an issue. I set up VisualSVN to listen on both ports 443 (with SSL) and 80 (without SSL) by adding the following to c:\program files\visualsvn server\conf\httpd-custom.conf and then restarting VisualSVN server:

Listen "80"
SSLEngine off
But I still saw chunking errors like this:
Could not read chunk size
What in the world is a chunking error? I tried Google, but all that turned up there was a not-so-useful discussion.

I figured I'd dig deeper, so I turned on errors in apache by adding the following to c:\program files\visualsvn server\conf\httpd-custom.conf and restarting VisualSVN: (I had to create the c:\errorlogs folder to get this to work)
ErrorLog c:/errorlogs/visualsvn_apache.log
LogLevel warn
I then saw this in the apache log:

[Tue Sep 07 23:05:16 2010] [error] [client 192.168.3.33] Provider encountered an error while streaming a REPORT response. [500, #0]
[Tue Sep 07 23:05:16 2010] [error] [client 192.168.3.33] A failure occurred while driving the update report editor [500, #620018]
[Tue Sep 07 23:05:16 2010] [error] [client 192.168.3.33] Error writing base64 data: APR does not understand this error code [500, #620018]
That finally gave me a little better error message to search for. After much more googling, I found 3 possible problems:
- Issue with VMWare Nat (the server and client were both running on virtual machines):
- Memory Leak
- HTTP Timeout

I first tried the VMWare NAT issue. I removed all possible NAT problems by running the SVN client on the same box as the SVN server, but the problem didn't go away. The Timeout issue was the next easiest one to try.

To address the timeout issue, I increased the timeout in the apache config to 30 minutes by adding this line to c:\program files\visualsvn server\conf\httpd-custom.conf and restarting VisualSVN:
Timeout 1800
And that fixed the problem. The scan of our database / SVN server was taking about 15 minutes (tons of tables and stored procedures, with the scan running on a somewhat slow development server). However, the Apache timeout was set to around 10 minutes. So after 10 minutes, Apache gave up, which caused the chunking error, which then caused the client software to throw the error.

Please let me know in the comments if you have run into similar problems, or if I need to clarify this at all.

5 comments:

Oo Ice Deep oO said...

My svn gives the error immediately, which seems that in my instance the time out would not be the problem. Any ideas on that?

Tim said...

The other two possibilities I ran into were that it was either a memory leak or a VMWare NAT problem. See the links above for more information.

Inarius said...

I too receive this error fairly quickly (within a minute or two). The Timeout increase hasn't solved the problem, but unless I'm paranoid it has improved things. Either that, or simply restarting VSVN increases the chances of operations completing.

We are also not running VMWare, and I'm not sure how to investigate the memory leak.

tanderson said...

I get the same error when doing an svn update and a .svn directory exists that isn't in the repository (I'd reverted some directory renames).

Turning on warnings as mentioned above gives:
Provider encountered an error while streaming a REPORT response. [404, #0]
A failure occurred while driving the update report editor [404, #160013]
Working copy path 'installers/pom.xml' does not exist in repository [404, #160013]

After removing the offending directory the problem went away.

Anonymous said...

I had the same problem after manually deleting and replacing a repository folder. I got it solved by restarting the "VisualSVN Server" service.