Sorry about that. I wasn't sure where to post it, since the question seems
to relate to implementation details of Subversion. I have reposted to
On Tue, Aug 26, 2008 at 10:17 AM, Julian Foad <julianfoad_at_btopenworld.com>wrote:
> Hi JJ. This email list is for discussing the development of Subversion,
> not about using it. Please post your query to the "users@" list instead.
> - Julian
> On Tue, 2008-08-26 at 06:56 -0500, JJ wrote:
> > Hi,
> > I have a Solaris 10 server running Subversion 1.5.1 served by Apache
> > 2.2.9 sitting behind an f5 content switch. The content switch
> > redirects all traffic to the one Subversion server. In case of
> > emergencies we can manually redirect the content switch to a secondary
> > server that is synced to with svnsync. In general though, the traffic
> > is all directed to one server.
> > This setup works fine in most cases. We have run into one odd problem
> > though.
> > On Windows, if I checkout a working copy and try to store it on NAS
> > via a mapped drive, part way through the checkout I get the following
> > error and the checkout aborts.
> > svn: REPORT request failed on '/svn/REPONAME/!svn/vcc/default'
> > svn: REPORT of '/svn/REPONAME/!svn/vcc/default': Could not read
> > response body: An existing connection was forcibly closed by the
> > remote host. (http://SVNSERVER)
> > The error does not occur when the working copy is stored locally, or
> > when the working copy is stored on NAS but I connect directly to the
> > server instead of the content switch.
> > A member of the network team here did a trace during checkout numerous
> > times and determined the following.
> > "
> > We noted in the traces that the client TCP Receive Window drops to 0,
> > indicating he can't receive any more data. He sends a zero window
> > probe about 8 times over about 45 seconds, after which time the server
> > resets the connection.
> > I cannot tell why the client TCP window goes to 0 when the traffic is
> > through the content switch, but not when it goes directly to the
> > server. I think a ticket should be opened with the vendor for the
> > client program to see if they've encountered this before.
> > "
> > Does anyone have any idea why this is happening? Should I change some
> > setting with Apache so the connection isn't closed? I realize NAS
> > here is slow, but we have a need for it. I just want to ensure that
> > the checkout isn't killed by the server.
> > Thanks,
> > JJ
Received on 2008-08-26 17:21:26 CEST