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 SS DST DS PROTO LEN ---- -------- ---- -- ----- -- ---- ---- 64459 936.018427 10.74.40.232 80 172.17.37.63 50798 HTTP 1434 Continuation or non-HTTP traffic 64460 936.018429 10.74.40.232 80 172.17.37.63 50798 HTTP 115 Continuation or non-HTTP traffic 64461 936.018441 172.17.37.63 50798 10.74.40.232 80 TCP 54 50798 > 80 [ACK] Seq=6565 Ack=65979260 Win=20474 Len=0 64462 938.661108 172.17.37.63 50798 10.74.40.232 80 TCP 54 [TCP Window Update] 50798 > 80 [ACK] Seq=6565 Ack=65979260 Win=65535 Len=0 64463 940.355624 172.17.37.63 50798 10.74.40.232 80 TCP 54 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.xxxxxx.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): 33494 647.944208 10.74.40.232 80 172.17.37.63 50167 HTTP 883 Continuation or non-HTTP traffic 33495 647.944218 172.17.37.63 50167 10.74.40.232 80 TCP 54 50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=24686 Len=0 33496 647.948777 172.17.37.63 50167 10.74.40.232 80 TCP 54 [TCP Window Update] 50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=28158 Len=0 33497 647.949267 172.17.37.63 50167 10.74.40.232 80 TCP 54 [TCP Window Update] 50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=65535 Len=0 33498 647.996754 172.17.37.63 50167 10.74.40.232 80 TCP 54 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.
