FW: issue #3264 Regarding: http://subversion.tigris.org/issues/show_bug.cgi?id=3264
(I did not get any acceptance reply on this email. Hence resending it).
From: lakhi...@hotmail.com
To: users@subversion.apache.org
Subject: issue #3264
Date: Thu, 16 Jun 2011 15:41:34 -0700
I have some information on this issue.
http://subversion.tigris.org/issues/show_bug.cgi?id=3264
(Hoping we could get a fix for this. The workaround is not really okay for
automatic scripts).
Running svn client either from cli (cygwin) (or from gui: tortioise-svn) from
relatively slow VMs.
A relatively large repository is being checked out. VM is slow, and there are
lots of instances where
svn client TCP windows goes to zero, and then opens up again. (As against a
relatively fast client, where
such fluctuations were not seen). client setting: http-timeout = 1800. This
is from a cli/cygwin client:
wireshark capture: (last few packets) client
(172.17.37.63) and subversion server (10.74.40.232)
PKT#Time (seconds) SRC SSDST DS PROTO
LEN
-- - --
64459936.01842710.74.40.23280172.17.37.6350798HTTP
1434 Continuation or non-HTTP traffic
64460936.01842910.74.40.23280172.17.37.6350798HTTP
115Continuation or non-HTTP traffic
64461936.018441172.17.37.635079810.74.40.23280TCP54
50798 80 [ACK] Seq=6565 Ack=65979260 Win=20474 Len=0
64462938.661108172.17.37.635079810.74.40.23280TCP54
[TCP Window Update] 50798 80 [ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
64463940.355624172.17.37.635079810.74.40.23280TCP54
50798 80 [FIN, ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
--
Client bails out saying:
svn: REPORT of '/xxx/yyy/!svn/vcc/default': Could not read response body:
connection was closed by server (http://subversion.xx.com)
Clearly, this client is not waiting enough for the server to send more data.
There is a delay of about half a second where nothing is received from the
server. After the second ACK from client (172.17.37.63) to subversion server
(10.74.40.232) the next packet is has a FIN..! Server has been silent
for approximately 4 seconds in the end --whether it reset or is just preparing
data to send I can not say, though server apache error-logs have errors showing
it could not write base64 data, but that could be the result of this client
sending a FIN. After all, server did not close the TCP connection.
In some prior runs, where I captured the whole session, the gap between server'
last data packet and svn client sending a FIN is much smaller (0.05 seconds,
approx):
33494647.94420810.74.40.23280172.17.37.6350167HTTP
883Continuation or non-HTTP traffic
33495647.944218172.17.37.635016710.74.40.23280TCP54
50167 80 [ACK] Seq=6564 Ack=50422857 Win=24686 Len=0
33496647.948777172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 80 [ACK] Seq=6564 Ack=50422857 Win=28158 Len=0
33497647.949267172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 80 [ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
33498647.996754172.17.37.635016710.74.40.23280TCP54
50167 80 [FIN, ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
bash-3.2$ svn --version
svn, version 1.6.11 (r934486)
compiled Apr 19 2010, 12:23:49
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
Thank you.
issue #3264
I have some information on this issue.
http://subversion.tigris.org/issues/show_bug.cgi?id=3264
(Hoping we could get a fix for this. The workaround is not really okay for
automatic scripts).
Running svn client either from cli (cygwin) (or from gui: tortioise-svn) from
relatively slow VMs.
A relatively large repository is being checked out. VM is slow, and there are
lots of instances where
svn client TCP windows goes to zero, and then opens up again. (As against a
relatively fast client, where
such fluctuations were not seen). client setting: http-timeout = 1800. This
is from a cli/cygwin client:
wireshark capture: (last few packets) client
(172.17.37.63) and subversion server (10.74.40.232)
PKT#Time (seconds) SRC SSDST DS PROTO
LEN
-- - --
64459936.01842710.74.40.23280172.17.37.6350798HTTP
1434 Continuation or non-HTTP traffic
64460936.01842910.74.40.23280172.17.37.6350798HTTP
115Continuation or non-HTTP traffic
64461936.018441172.17.37.635079810.74.40.23280TCP54
50798 80 [ACK] Seq=6565 Ack=65979260 Win=20474 Len=0
64462938.661108172.17.37.635079810.74.40.23280TCP54
[TCP Window Update] 50798 80 [ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
64463940.355624172.17.37.635079810.74.40.23280TCP54
50798 80 [FIN, ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
--
Client bails out saying:
svn: REPORT of '/xxx/yyy/!svn/vcc/default': Could not read response body:
connection was closed by server (http://subversion.xx.com)
Clearly, this client is not waiting enough for the server to send more data.
There is a delay of about half a second where nothing is received from the
server. After the second ACK from client (172.17.37.63) to subversion server
(10.74.40.232) the next packet is has a FIN..! Server has been silent
for approximately 4 seconds in the end --whether it reset or is just preparing
data to send I can not say, though server apache error-logs have errors showing
it could not write base64 data, but that could be the result of this client
sending a FIN. After all, server did not close the TCP connection.
In some prior runs, where I captured the whole session, the gap between server'
last data packet and svn client sending a FIN is much smaller (0.05 seconds,
approx):
33494647.94420810.74.40.23280172.17.37.6350167HTTP
883Continuation or non-HTTP traffic
33495647.944218172.17.37.635016710.74.40.23280TCP54
50167 80 [ACK] Seq=6564 Ack=50422857 Win=24686 Len=0
33496647.948777172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 80 [ACK] Seq=6564 Ack=50422857 Win=28158 Len=0
33497647.949267172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 80 [ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
33498647.996754172.17.37.635016710.74.40.23280TCP54
50167 80 [FIN, ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
bash-3.2$ svn --version
svn, version 1.6.11 (r934486)
compiled Apr 19 2010, 12:23:49
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
Thank you.
