[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Slow VM, svn client drops connection with FIN packet

From: <stuartm.coding_at_gmail.com>
Date: Mon, 23 Dec 2013 09:11:48 -0800 (PST)

On Tuesday, December 17, 2013 10:32:34 AM UTC-5, Branko Čibej wrote:
>
> On 17.12.2013 16:19, Stuart MacDonald wrote:
> > The Wireshark trace shows clearly and conclusively this is a bug in
> > the client. The client drops the connection by sending a FIN packet
> > unexpectedly.
>
> It could be waiting for a response from the proxy that never reaches the
> client, and dropping the connection after a timeout.
>
> Regardless, you should still try to reproduce this with the latest
> client (ideally, both latest 1.7 and 1.8) to determine if the problem
> has been fixed. Especially in 1.8, there have been a lot of improvements
> in the HTTP protocol driver.
>

I'm using WANdisco's packages to test with, as it turned out to be easier
to get those set up than to compile from source with all the optional bits
I need.

I have seen the exact same issue on 1.7.14:
svn: E175002: REPORT of '/svn/repos/<name>/!svn/me': Could not read
response body: connection was closed by server (http://<server>)
and the Wireshark capture shows the client sending a [FIN, ACK] to close
the connection, despite it only being a fraction of a second since the last
server traffic. This always occurs just after the TCP window opening up
again, not sure if that's significant.

This *also* occurs on 1.8.5, although the error message is more informative:
svn: E120106: ra_serf: The server sent a truncated HTTP response body.
The Wireshark capture is *exactly* *identical*; after some server traffic,
the TCP window opens up and the client sends a [FIN, ACK] to close the
connection.

Having taken a closer look at the network captures; the failure pattern is
always:
- 1380 byte packets from the server
- an ACK from the client
- a TCP window update from the client (the window hadn't gone to 0 in any
cases, this is just a regular update)
- in one case there's another window update from the client
- a delay of 0 - 4 seconds where there is no traffic in either direction
- the client sends the [FIN, ACK]

Now, I'm not sure what constitutes a truncated HTTP response body, as the
traffic looks the same in both cases, large blocks of encoded data. So I
think the 1.8.x error message is also incorrect, but possibly less
incorrect than the 1.7.x error message.

What's the next step?

...Stu

 
Received on 2013-12-23 18:12:29 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.