Hi Manu,
On 11/28/2017 12:22 PM, Emmanuel Hocdet wrote:
Hi Willy,
Le 28 nov. 2017 à 07:33, Willy Tarreau <w...@1wt.eu <mailto:w...@1wt.eu>> a
écrit :
Hi Manu,
On Mon, Nov 27, 2017 at 06:21:50PM +0100, Emmanuel Hocdet wrote:
Hi Willy,
Le 18 nov. 2017 à 12:28, Willy Tarreau <w...@1wt.eu <mailto:w...@1wt.eu>>
a écrit :
Hi Manu,
On Fri, Nov 17, 2017 at 05:14:11PM +0100, Emmanuel Hocdet wrote:
In master-worker mode with peers, old worker never died after a
reload (kill -USR2).
Tested without traffic, with/without threads.
Without peers, no problems.
Thanks for the report. I'm currently working on an issue causing some
streams never to end, and it *could* possibly also affect peers. We'll
have to try again once I manage to sort this out.
same issue with 1.8.0.
Then I'll need a reproducer because I couldn't reproduce it.
ok, i should have something strange because it’s easy to reproduce in my
environnement.
When i look lsof i see on master:
haproxy 21355 root 4u IPv4 39007164 0t0 TCP
10.101.20.4:943 (LISTEN)
it’s link to self ip configuration "peer L6_2 10.101.20.4:943"
Master listen on peer? really?
on each reload (kill -USR2) on more LISTEN appears
In fact without reloading anything there are race condition issues in
peers code.
I was working on another issue when I noticed this new one:
With only two configured peers, I see that they try to reconnect to each
others every 10s in place of 5s as before.
This is as if a peer was blocking the other one during 5s and preventing
it to reconnect... or something similar.
Then, after a few cycles, they try to connect to each other exactly at
the same time. Only a "hello" message, is sent from both side without
receiving any response.
