You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by JJ <eg...@gmail.com> on 2008/08/26 11:56:03 UTC
Connection closed when going through content switch
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
Re: Connection closed when going through content switch
Posted by JJ <eg...@gmail.com>.
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
users.
Thanks,
JJ
On Tue, Aug 26, 2008 at 10:17 AM, Julian Foad <ju...@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.
> Thanks.
>
> - 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
> >
>
>
Re: Connection closed when going through content switch
Posted by Julian Foad <ju...@btopenworld.com>.
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.
Thanks.
- 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Connection closed when going through content switch
Posted by JJ <eg...@gmail.com>.
The content switch supports webdav. It works fine in every other
circumstance. It only fails when checking out through the switch and
storing to a working copy on a windows drive mapped to NAS. The slow write
to NAS causes the client buffer to fill up, it keeps telling the server the
client buffer is full and eventually the server closes the connection. I
don't understand why that would happen through a content switch but not when
connecting directly to the host.
On Tue, Aug 26, 2008 at 10:28 AM, <da...@jpmorgan.com> wrote:
> Check that the f5 content switch supports webdav.
>
> Cisco content engines don't - it could be a similar problem to that.
>
> See this thread for details:
>
> http://svn.haxx.se/users/archive-2008-05/0022.shtml
>
> HTH,
>
> Dg.
> --
> David Grierson
> JPMorgan - IB Architecture - Source Code Management Consultant
> GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson@jpmorgan.com
> Alhambra House 6th floor, 45 Waterloo Street, Glasgow G2 6HS
>
>
>
>
> JJ <eg...@gmail.com>
> 26/08/2008 16:19
>
> To
> users@subversion.tigris.org
> cc
>
> Subject
> Connection closed when going through content switch
>
>
>
>
>
>
> 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
>
>
> Generally, this communication is for informational purposes only
> and it is not intended as an offer or solicitation for the purchase
> or sale of any financial instrument or as an official confirmation
> of any transaction. In the event you are receiving the offering
> materials attached below related to your interest in hedge funds or
> private equity, this communication may be intended as an offer or
> solicitation for the purchase or sale of such fund(s). All market
> prices, data and other information are not warranted as to
> completeness or accuracy and are subject to change without notice.
> Any comments or statements made herein do not necessarily reflect
> those of JPMorgan Chase & Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission and any
> attachments are believed to be free of any virus or other defect
> that might affect any computer system into which it is received and
> opened, it is the responsibility of the recipient to ensure that it
> is virus free and no responsibility is accepted by JPMorgan Chase &
> Co., its subsidiaries and affiliates, as applicable, for any loss
> or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and
> destroy the material in its entirety, whether in electronic or hard
> copy format. Thank you.
> Please refer to http://www.jpmorgan.com/pages/disclosures for
> disclosures relating to UK legal entities.
>
Re: Connection closed when going through content switch
Posted by da...@jpmorgan.com.
Check that the f5 content switch supports webdav.
Cisco content engines don't - it could be a similar problem to that.
See this thread for details:
http://svn.haxx.se/users/archive-2008-05/0022.shtml
HTH,
Dg.
--
David Grierson
JPMorgan - IB Architecture - Source Code Management Consultant
GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson@jpmorgan.com
Alhambra House 6th floor, 45 Waterloo Street, Glasgow G2 6HS
JJ <eg...@gmail.com>
26/08/2008 16:19
To
users@subversion.tigris.org
cc
Subject
Connection closed when going through content switch
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
Generally, this communication is for informational purposes only
and it is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation
of any transaction. In the event you are receiving the offering
materials attached below related to your interest in hedge funds or
private equity, this communication may be intended as an offer or
solicitation for the purchase or sale of such fund(s). All market
prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice.
Any comments or statements made herein do not necessarily reflect
those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Connection closed when going through content switch
Posted by JJ <eg...@gmail.com>.
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