Hi Igor, On Fri, Nov 03, 2017 at 09:47:59AM +1100, Igor Cicimov wrote: > How about cases that have light load :-).
It's not a matter of load, it's a matter of being totally unreliable. You just need a single request to a dead server and your haproxy will be frozen until you kill and restart it. And worse, by claiming that it seldom works, some people will blindly deploy it then complain that haproxy freezes all the time. No, it's really not the right way to do it at all. > I've been asking/waiting for > this feature for a long time and think it is (going to be ) a very > valuable addition to haproxy. Anyway, if you had experienced some issues > with the lib I wonder what is the way Apache and Nginx are doing it without > any performance impact? (or so we think?) > > Maybe I would argue that as a feature it should be included in haproxy > anyway and be left to the users to opt for using it or not, with heavy > warning about possible performance impact. There's little *performance* impact, but a huge *reliability* impact. And that's out of question here. We created SPOE *exactly* for this type of thing. And here the code in the patch looks simple, I'm pretty sure it will be easy to port into one of the example SPOE modules. It will also bring other benefits such as having high availability and load balancing over multiple LDAP servers, not having to cut/reopen the connections on restart, not having to restart haproxy to modify the ldap config etc. For such problematic libs, SPOE is *the* right solution. You can even use threads or anything you want to workaround the broken lib and haproxy's traffic will never be affected. Willy
