I replied yesterday, but my post seems to have disappeared. I figured it out, and the key was your reproduction and my realisation I wasn't seeing a FIN from my server. It turns out that in every case the last 392598 71.906863000 10.222.3.88 10.14.11.50 HTTP 1434 Continuation or non-HTTP traffic line from the server is actually also a FIN packet, and Wireshark (or the TCP dissector) is "hiding" that; if I look at the packet I can see the FIN flag, but it's not mentioned in the Info field in the packet list. So the FINs from my client are close handshake responses not initiations, and it is the server timing out after all.
Thanks for the help. I'm checking with my IT dept to see if they can bump up the timeout. ...Stu On Tuesday, January 14, 2014 11:55:39 AM UTC-5, Philip Martin wrote: > > Stuart MacDonald <stuartm...@gmail.com <javascript:>> writes: > > > svn: E175002: REPORT of '/svn/repos/deckard-65x/!svn/me': Could not read > > response body: connection was closed by server (http://foundry51.qnx.com) > > > I can provoke this on my local LAN by setting the Apache timeout on the > server to a low value such as 5 seconds. Then I run a checkout that > generates a large REPORT response and I use gdb to interrupt the client > at subversion/libsvn_ra_neon/fetch.c:1709 so that the client is in the > middle of reading the repsonse. I wait for the server timeout to > expire and then resume the client and I get the error: > > svn: E175002: REPORT of '/obj/repo/!svn/me': Could not read response body: > connection was closed by server (http://peri.local:8888) > > One fix is to increase the server timeout to handle your slow client. > > -- > Philip Martin | Subversion Committer > WANdisco // *Non-Stop Data* >
