Please remove me

[Sparr]

From this list

Re: Reset near end of connection for slow transfers

[Sparr]

I wanted to follow up and mention that we figured out the problem. The
nolinger option was producing this behavior. Disabling it seems to
have completely eliminated the issue.

On Mon, Sep 8, 2014 at 12:55 PM, Sparr spa...@gmail.com wrote:
 I've got haproxy and apache on separate VMs in the same environment.
 When I download slowly (naturally across the internet or artificially
 with curl --limit-rate) I often get a connection failure near the end
 of the transfer. Usually at 99%, rarely as early as 87% on especially
 slow connections. If I make my download request directly to the apache
 server then there are no failures.

Reset near end of connection for slow transfers

[Sparr]

Greetings. I've joined this list after bringing this problem to the
haproxy IRC channel and it being suggested that I try here.

I've got haproxy and apache on separate VMs in the same environment.
When I download slowly (naturally across the internet or artificially
with curl --limit-rate) I often get a connection failure near the end
of the transfer. Usually at 99%, rarely as early as 87% on especially
slow connections. If I make my download request directly to the apache
server then there are no failures.

Here is the tail end of a tcpdump on the haproxy server during such a failure:

12:09:59.719048 IP HAPROXYIP.http  CLIENTIP.64339: Flags [.], seq
25815027:25817831, ack 128, win 220, options [nop,nop,TS val 334759695
ecr 1732745683], length 2804
12:09:59.719057 IP HAPROXYIP.http  CLIENTIP.64339: Flags [.], seq
25817831:25820635, ack 128, win 220, options [nop,nop,TS val 334759695
ecr 1732745683], length 2804
12:09:59.719065 IP HAPROXYIP.http  CLIENTIP.64339: Flags [.], seq
25820635:25823439, ack 128, win 220, options [nop,nop,TS val 334759695
ecr 1732745683], length 2804
12:09:59.719072 IP HAPROXYIP.http  CLIENTIP.64339: Flags [.], seq
25823439:25826243, ack 128, win 220, options [nop,nop,TS val 334759695
ecr 1732745683], length 2804
12:09:59.723855 IP CLIENTIP.64339  HAPROXYIP.http: Flags [.], ack
25812223, win 1037, options [nop,nop,TS val 1732745686 ecr 334759695],
length 0
12:09:59.724240 IP CLIENTIP.64339  HAPROXYIP.http: Flags [.], ack
25820635, win 512, options [nop,nop,TS val 1732745686 ecr 334759695],
length 0
12:09:59.923407 IP HAPROXYIP.http  CLIENTIP.64339: Flags [.], seq
25826243:25827645, ack 128, win 220, options [nop,nop,TS val 334759746
ecr 1732745686], length 1402
12:09:59.923465 IP HAPROXYIP.http  CLIENTIP.64339: Flags [R.], seq
25827645, ack 128, win 220, options [nop,nop,TS val 334759746 ecr
1732745686], length 0
12:09:59.923905 IP CLIENTIP.64339  HAPROXYIP.http: Flags [.], ack
25826243, win 1213, options [nop,nop,TS val 1732745882 ecr 334759695],
length 0
12:09:59.923933 IP HAPROXYIP.http  CLIENTIP.64339: Flags [R], seq
4290808590, win 0, length 0

Here is the haproxy log entry for that same transfer:

lb02/messages:Sep  8 12:09:58 lb02 haproxy[19704]: CLIENTIP:64339
[08/Sep/2014:12:05:53.211] LISTEN LISTEN/SERVER 0/0/0/2/245710 200
25978565 - -  40/40/21/5/0 0/0 GET /path/to/25MBfile HTTP/1.1

25978565 is the correct size for the file. 25827273 is how many bytes
the client received.

It seems like the haproxy logging facility thinks that the transfer
was successful (hence the  status result and correct file size in
the log entry). However, something that I can't identify is initiating
that tcp reset before all the bytes go across the network. I'd like to
figure out what.