Thank you everyone for pitching in. I will take another stab at explaining my case/context.
So I have a component which issues a lot of requests over a keep-alive connection to HAProxy. In the middle there is a TCP Load Balancer (hardware) which only intercepts new tcp connection requests. Once the tcp connection is established, the client can send as many HTTP requests as it wants. For lack of a better term, it becomes sticky. Usually clients (browsers) would send a bunch of requests and then go away.. effectively closing the TCP connection. In my case, the component keeps going. If I force HAProxy to close the keep-alive connection, even when its being actively used, the client issues a new TCP connection. And the load balancer can send it somewhere else (to another HAProxy instance). In this case, I am not stopping HAproxy for maintenance. I just want TCP connections to be _not_ established for a long time. Thanks On Wed, Jun 8, 2016 at 1:37 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Wed, Jun 08, 2016 at 04:17:58PM -0400, CJ Ess wrote: >> I personally don't have a need to limit requests the haproxy side at the >> moment, I'm just thought I'd try to help Manas make his case. Hes basically >> saying that he wants the option to close the client connection after the >> nth request and that seems pretty reasonable to me. > > But quite frankly it's not a use case. Believe me, we're quite used to > get requests from people *thinking* they need a certain feature while > in fact they need something totally different, just because they think > that it's the last missing piece of their puzzle. Implementing something > specific like this which will definitely cause new issues and bug reports > here is not going to happen without a really good reason, and for now all > I can read is "I'd like to close after N request". We could also implement > just a sample fetch to return the request number so that it's possible to > add an ACL to block past some point but all of this seems very fishy for > now :-/ > >> Maybe it would help him >> with DDOS or to manage the number of ports used by the server, If one >> server becomes particularly loaded then forcing the clients to reconnect >> gives his load balancer an opportunity to move load around to less utilized >> servers. I'm just speculating. > > That's exactly why I'm interested in the *real* use case, because very likely > this alone will not be enough and will just spray some paint on the real > issue. > > Cheers, > Willy >
