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.

> Will update the srv_conn_free fetch with similar changes pending outcome
> of this one.

OK, thanks.


Reply via email to