On 2018/8/25 01:30, Willy Tarreau wrote: > On Fri, Aug 24, 2018 at 06:18:23PM -0400, Patrick Hemmer wrote: >>> I disagree with making a special case above for maxconn 0. In fact for me >>> it just means that such a server cannot accept connections, so it simply >>> doesn't count in the sum, just as if it were not present. >> On a server, maxconn=0 means unlimited, not that it can't accept >> connections. If we return 0, how will the caller differentiate between >> unlimited, and no free connections? > Ah OK I didn't remember about this one, the it completely makes sense. > Thanks for refreshing me on this one. It deserves a comment because it's > not obvious ;-) The current comment says the configuration is stupid > while in fact it's just that this server is not limited. I think I > still don't agree much with reporting -1 even if I'm the one having > set it for connslots, which probably means I changed my mind regarding > this. But I'm not seeing any better value that can easily be checked, > so that's probably the least bad solution. > >> Also made 2 additional changes. One is to handle dynamic maxconn. The >> other is to handle the case where the maxconn is adjusted (via stats >> socket) to be less than the number of currently active connections, >> which would result in the value wrapping. > Good point. I'll adjust the doc then since it still says that it doesn't > handle dynamic maxconn. Just let me know if you agree, and I'll do it > myself to save you from having to respin a patch. Sure, that's fine with me. Thanks :-)
>> Will update the srv_conn_free fetch with similar changes pending outcome >> of this one. > OK, thanks. > > Willy I'll adjust the other sample fetch tomorrow. -Patrick
