Resend, ungarbled. > -----Original Message----- > From: Robert Segall [mailto:[email protected]] > Sent: Thursday, February 11, 2010 11:32 AM > To: [email protected] > Subject: Re: [Pound Mailing List] Disabling a Backend w/ PoundCtl > > On Tue, 2010-02-02 at 21:54 +0000, Joe Gooch wrote: > > When you disable a backend, it can still receive requests that are > already "stuck" to the backend. Which is fine, that's what I would > prefer as well. > > > > However, the comment in svc.c is wrong, around line 572: > > disable_only == 1: mark as disabled, remove sessions > > > > Since it does not remove sessions. > > Correct. We'll fix that in the next release. > > > In addition, the get_backend call does not do the right thing if all > backends are dead or disabled. Because the tot_pri of the service is > <=0, it always returns svc->emergency. Which is fine, UNLESS one of > the backends is disabled, and a session exists for that connection. In > that case, it should return the disabled backend. > > I don't think that's right. Disabled is disabled.
In this case, disabled is not disabled. :) Use case 1) 2 Backends, 1 of which is Disabled Tot_pri is >0 Sessions are consulted All new requests (session cache misses) are sent to the active backend. All requests that match a session to the disabled backend are still sent to the disabled backend. (hence, disabled is not disabled, it just means it isn't receiving NEW sessions) Use case 2) 2 Backends, Both are disabled Tot_pri = 0 Sessions are NOT consulted. get_backend ALWAYS returns svc->emergency. Existing sessions are NOT sent to their "stuck" backend. This is inconsistent with case 1. Expected behavior: Sessions are consulted All new requests (session cache misses) are sent to the svc->emergency backend. All requests that match a session are still sent to their appropriate disabled backend. The existing code is only correct when sessions are not used. Unless my expected behavior is not the intended behavior, in which case, use case 1 is, at best, inconsistent. Joe -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
