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..._at_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*
>
Received on 2014-01-15 17:53:49 CET