You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pa...@L-3Com.com on 2014/10/14 16:43:52 UTC

SVN 1.8 timeout fix

We just upgraded from Subversion 1.7 to 1.8 and almost immediately began getting timeouts checking out larger repositories.  The Tortoise file transfer rate would quickly diminish to 0 and eventually return an error.  The subversion command client would terminate with "svn E175012 Connection timed out."  I found several reports from other who encountered the same thing, but there were no solutions offered.   Some people said they simply reverted back to 1.7.

I monitored the network traffic and saw the tcp connections were opened and remained in the FIN_WAIT_2 state.  http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html suggests a client side bug and to set KeepAlive Off if you're unable to make mods to your client.

Setting KeepAlive Off on my apache server fixed the issue.

Paul Gillis
Engineering Support Specialist
L-3 Warrior Systems, Insight
9 Akira Way, Londonderry, NH 03053
(603) 551-6167
Paul.Gillis@L-3com.com


Re: SVN 1.8 timeout fix

Posted by Branko Čibej <br...@wandisco.com>.
On 15.10.2014 14:00, Philip Martin wrote:
> <Pa...@L-3Com.com> writes:
>
>> When I initially used the default skelta-mode, small checkouts and
>> commits worked perfectly fine. Large checkouts or commits would begin
>> normally but the file transfer rate would quickly drop to 0 and the
>> operation would time out.  Increasing MaxKeepAliveRequests to 1000
>> didn't help.  When I disabled KeepAlive, it solved the problem.
> I don't know what would cause that.  A skelta-mode checkout uses a large
> number of small requests while a bulk-mode checkout uses a small number
> of large requests.  Is there an HTTP proxy between the client and
> server?

Note that it's not necessarily an HTTP proxy; we've had at least one
confirmed case of the Cisco ASA with deep packet inspection enabled
producing exactly this kind of result; that turned out not to be
specific to Subversion at all.

-- Brane


Re: SVN 1.8 timeout fix

Posted by Lieven Govaerts <lg...@mobsol.be>.
On Wed, Oct 15, 2014 at 2:10 PM,  <Pa...@l-3com.com> wrote:
> There is no proxy between the client and server. As my original email stated, I could see using netstat that there were tcp connections left in the FIN_WAIT_2 state and the Apache documentation suggests this could be a bug in the client. Also as the Apache documentation suggested, disabling KeepAlive resolved the issue.  See http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html

The hypothesis stated here is that serf isn't closing its connections
correctly when they are closed by the server, on Windows. While I
don't think anything is wrong with that part of the serf code, serf
testing is mostly done by using short-lived processes so if there's an
issue it might not be very visible. I'll have a look later.

>
> Whatever the problem is, when I disable Keepalive I can't browse the repositories from a browser. http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate suggests it is a serf bug.

That's not what that mail suggests. It talks about an old bug where
svn+serf can't authenticate to a server using the Digest
authentication scheme when that server is configured with KeepAlive
off. That issue was a) solved a long time ago, and b) as others have
said is unrelated to what you're seeing.

Lieven

>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: Wednesday, October 15, 2014 8:01 AM
> To: Gillis, Paul @ ESG - WSS - Insight
> Cc: users@subversion.apache.org
> Subject: Re: SVN 1.8 timeout fix
>
> <Pa...@L-3Com.com> writes:
>
>> When I initially used the default skelta-mode, small checkouts and
>> commits worked perfectly fine. Large checkouts or commits would begin
>> normally but the file transfer rate would quickly drop to 0 and the
>> operation would time out.  Increasing MaxKeepAliveRequests to 1000
>> didn't help.  When I disabled KeepAlive, it solved the problem.
>
> I don't know what would cause that.  A skelta-mode checkout uses a large number of small requests while a bulk-mode checkout uses a small number of large requests.  Is there an HTTP proxy between the client and server?
>
>> However, with KeepAlive disabled, I discovered we can't browse
>> repositories from a web browser. Apparently, this is a know serf bug.
>> http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate.
>
> serf is a client-side library.  There is no way a serf bug can affect a web browser (I'm guessing you have not written your own web browser that uses serf :)  You must be seeing some other problem.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

Re: SVN 1.8 timeout fix

Posted by Philip Martin <ph...@wandisco.com>.
<Pa...@L-3Com.com> writes:

> Whatever the problem is, when I disable Keepalive I can't browse the
> repositories from a
> browser. http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate
> suggests it is a serf bug.

No, it cannot be a serf bug.  The browser doesn't use serf.  The server
doesn't use serf.  Only the Subversion client uses serf.  You are seeing
some other problem.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: SVN 1.8 timeout fix

Posted by Pa...@L-3Com.com.
There is no proxy between the client and server. As my original email stated, I could see using netstat that there were tcp connections left in the FIN_WAIT_2 state and the Apache documentation suggests this could be a bug in the client. Also as the Apache documentation suggested, disabling KeepAlive resolved the issue.  See http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html

Whatever the problem is, when I disable Keepalive I can't browse the repositories from a browser. http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate suggests it is a serf bug.  


-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com] 
Sent: Wednesday, October 15, 2014 8:01 AM
To: Gillis, Paul @ ESG - WSS - Insight
Cc: users@subversion.apache.org
Subject: Re: SVN 1.8 timeout fix

<Pa...@L-3Com.com> writes:

> When I initially used the default skelta-mode, small checkouts and 
> commits worked perfectly fine. Large checkouts or commits would begin 
> normally but the file transfer rate would quickly drop to 0 and the 
> operation would time out.  Increasing MaxKeepAliveRequests to 1000 
> didn't help.  When I disabled KeepAlive, it solved the problem.

I don't know what would cause that.  A skelta-mode checkout uses a large number of small requests while a bulk-mode checkout uses a small number of large requests.  Is there an HTTP proxy between the client and server?

> However, with KeepAlive disabled, I discovered we can't browse 
> repositories from a web browser. Apparently, this is a know serf bug. 
> http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate.

serf is a client-side library.  There is no way a serf bug can affect a web browser (I'm guessing you have not written your own web browser that uses serf :)  You must be seeing some other problem.

--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: SVN 1.8 timeout fix

Posted by Philip Martin <ph...@wandisco.com>.
<Pa...@L-3Com.com> writes:

> When I initially used the default skelta-mode, small checkouts and
> commits worked perfectly fine. Large checkouts or commits would begin
> normally but the file transfer rate would quickly drop to 0 and the
> operation would time out.  Increasing MaxKeepAliveRequests to 1000
> didn't help.  When I disabled KeepAlive, it solved the problem.

I don't know what would cause that.  A skelta-mode checkout uses a large
number of small requests while a bulk-mode checkout uses a small number
of large requests.  Is there an HTTP proxy between the client and
server?

> However, with KeepAlive disabled, I discovered we can't browse
> repositories from a web browser. Apparently, this is a know serf
> bug. http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate.

serf is a client-side library.  There is no way a serf bug can affect a
web browser (I'm guessing you have not written your own web browser that
uses serf :)  You must be seeing some other problem.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: SVN 1.8 timeout fix

Posted by Pa...@L-3Com.com.
When I say we upgraded from 1.7 to 1.8, we configured and deployed a new server running CollabNetSubversion-server-1.8.9-2-Win32 that replaced our 1.7 server.  All clients uninstalled 1.7, reinstalled 1.8 and rebooted. 

I just tried setting SVNAllowBulkUpdates to Prefer and I re-enabled KeepAlive setting MaxKeepAliveRequests to 1000. That also seems to work for us.  

When I initially used the default skelta-mode, small checkouts and commits worked perfectly fine. Large checkouts or commits would begin normally but the file transfer rate would quickly drop to 0 and the operation would time out.  Increasing MaxKeepAliveRequests to 1000 didn't help.  When I disabled KeepAlive, it solved the problem.  However, with KeepAlive disabled, I discovered we can't browse repositories from a web browser. Apparently, this is a know serf bug. http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate.

 
Paul Gillis
Engineering Support Specialist
L-3 Warrior Systems, Insight
9 Akira Way, Londonderry, NH 03053
(603) 551-6167
Paul.Gillis@L-3com.com

-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com] 
Sent: Tuesday, October 14, 2014 1:13 PM
To: Gillis, Paul @ ESG - WSS - Insight
Cc: users@subversion.apache.org
Subject: Re: SVN 1.8 timeout fix

<Pa...@L-3Com.com> writes:

> We just upgraded from Subversion 1.7 to 1.8 and almost immediately 
> began getting timeouts checking out larger repositories.  The Tortoise 
> file transfer rate would quickly diminish to 0 and eventually return 
> an error.  The subversion command client would terminate with "svn
> E175012 Connection timed out."  I found several reports from other who 
> encountered the same thing, but there were no solutions offered.  Some 
> people said they simply reverted back to 1.7.

I assume you are referring to an upgrade of the client from 1.7 to 1.8.
Did you also upgrade the server?  Which version is running on the server?

One change in 1.8 is that serf is used to handle HTTP on the client-side rather than neon.  The default client-side HTTP timeout when using neon is 60 minutes but when using serf it is 10 minutes.  A client can change its default timeout by setting servers:global:http-timeout.

If you upgraded the server to 1.8 then update/checkout will have switched to skelta-mode by default and I suppose configuring the client or server to use bulk-mode might solve the problem:

http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default

--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: SVN 1.8 timeout fix

Posted by Philip Martin <ph...@wandisco.com>.
<Pa...@L-3Com.com> writes:

> We just upgraded from Subversion 1.7 to 1.8 and almost immediately
> began getting timeouts checking out larger repositories.  The Tortoise
> file transfer rate would quickly diminish to 0 and eventually return
> an error.  The subversion command client would terminate with "svn
> E175012 Connection timed out."  I found several reports from other who
> encountered the same thing, but there were no solutions offered.  Some
> people said they simply reverted back to 1.7.

I assume you are referring to an upgrade of the client from 1.7 to 1.8.
Did you also upgrade the server?  Which version is running on the
server?

One change in 1.8 is that serf is used to handle HTTP on the client-side
rather than neon.  The default client-side HTTP timeout when using neon
is 60 minutes but when using serf it is 10 minutes.  A client can change
its default timeout by setting servers:global:http-timeout.

If you upgraded the server to 1.8 then update/checkout will have
switched to skelta-mode by default and I suppose configuring the client
or server to use bulk-mode might solve the problem:

http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*