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.mar...@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 <paul.gil...@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*
