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

Reply via email to