Le 12/10/2016 à 22:07, John Lanigan a écrit :
It’s only taken me 2 months to upgrade!
Once I figured out the process I dove straight in at the deep end and went up
to 1.6.9, it's been live a few days now without issues so I have enabled health
checking tonight on the nodes that were mis-reporting being down and they are
Great, thanks for the feedback.
Thank you for your help, and excellent work on the new HTML documentation, the
format is much more readable than the txt version for occasional users like me.
Thanks, it reminds me I have a todo list which is still growing. I
really need to find some times to fix some issues and re-enable the
automatic generation of the documentation : since I included all the
documentation files (for versions providing intro.txt, management.txt,
...), it's stuck to a release version until I run the process and
From: John Lanigan [mailto:john.lani...@coresoftware.ie]
Sent: Monday 8 August 2016 06:25
To: Cyril Bonté
Subject: RE: Problem with health checking
I'll try that, and also have the app server team compare their settings across
From: Cyril Bonté [mailto:cyril.bo...@free.fr]
Sent: Sunday 7 August 2016 20:28
To: John Lanigan
Subject: Re: Problem with health checking
Le 07/08/2016 à 21:17, John Lanigan a écrit :
http-check expect status 200
server hostingapp2_5041 172.17.2.40:5041 check
server hostingapp3_5041 172.17.2.50:5041 check
If I access all four of those URLs with lynx to show the headers from
the command line on the haproxy server I get the same result from each
server, instantaneous response and HTTP 200 status.
But the haproxy stats page reports L7 timeout if we add in a check on
the new app setup.
Any ideas what I need to check next?
I’ve been running haproxy 1.4.24 on centos 6.5 for over 2 years, load
balancing a pair of Oracle 11g app servers on Windows 2008r2.
Did you upgrade to the latest 1.4 to see if the issue remains ?
After reviewing the changelog with the configuration you have provided, I think
it comes from your http-check rules, due to a bug that has been fixed in 1.4.26
(about HTTP keep-alived connections with http-check) :
As a quick test, maybe you can disable keep-alive on your servers to verify