BUG/MEDIUM: peers: Peers CLOSE_WAIT issue.
authorFrédéric Lécaille <flecaille@haproxy.com>
Tue, 13 Jun 2017 14:39:57 +0000 (16:39 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 15 Jun 2017 08:47:40 +0000 (10:47 +0200)
commit5df119008a1485a297906299f2bbb13fb7e0de77
treef7d9e6b70bc76426ebace5e44e706977cbf211fe
parenta33510b215b9886d95360f2d60e558a8c2a57ec2
BUG/MEDIUM: peers: Peers CLOSE_WAIT issue.

A peer session which has just been created upon reconnect timeout expirations,
could be right after shutdown (at peer session level) because the remote
side peer could also righ after have connected. In such a case the underlying
TCP session was still running (connect()/accept()) and finally left in CLOSE_WAIT
state after the remote side stopped writting (shutdown(SHUT_WR)).

Now on, with this patch we never shutdown such peer sessions wich have just
been created. We leave them connect to the remote peer which is already
connected and must shutdown its own peer session.

Thanks to Patric Hemmer and Yves Lafon at w3.org for reporting this issue,
and for having tested this patch on the field.
Thanks also to Willy and Yelp blogs which helped me a lot in fixing it
(see https://www.haproxy.com/blog/truly-seamless-reloads-with-haproxy-no-more-hacks/ and
https://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.htmll).
src/peers.c