Re: [PATCH] [RFC] Decrease server health based on http responses / events

From: Krzysztof Olêdzki <ole#ans.pl>
Date: Thu, 10 Dec 2009 19:17:30 +0100

On 2009-12-10 08:39, Willy Tarreau wrote:
> Hi Krzysztof,

Hi Willy,

> (...)

>>> What are those "events" supposed to check for ? I've not found them 
>>> anywhere else.
>> Ineed. It is for pure TCP, where we can only track timeouts, resets, 
>> etc. However, I'm looking for a good place where to attach those checks, 
>> and for a better name - maybe "l3events"?

>
> "events" by itself might not be the proper name then. For instance, a
> timeout is precisely a lack of event.

It's a matter of definition, like if 0 is or is not a natural number. For me timeout *is* one of events, but no problem - we can choose a name that is intuitive for everyone.

> Maybe simply "errors" ? The
> other ones are not errors, just plain valid status codes after all.

OK, but we are not only going to observing errors, but also succesfull connections to clear error counter. So maybe simple "layer4" (for tcp) and "layer7" (for http) might be OK?

>>> I mean, maybe we could have sort of an error-react prefix
>>> with its few parameters afterwards. Maybe something in that spirit :
>>>
>>>   error-react to <event> by <action> after <limit>
>>>
>>> It's just an idea, not necessarily something to follow.
>> Something like "error-react to http-response by failcheck after 10"?

>
> yes, precisely. Another advantage would be that we could also
> allow the statement on regular backend config (even defaults)
> when it's supposed to be the same for all servers. It would
> then be handled just like the "source" keyword : per-server,
> then per-backend.

Right. A backend/default value is important. However, I think we:

• must use the same syntax for both backend's and server's configuration,
• don't need to require to always specify all parameters
• should keep current type of names: "type value" (not "to", "by", "after".

So, I'll be more happy with "on-error fail-check" than with "by fail-check", etc.

>>> Does this mean that we're now forced to at least switch to fast
>>> inter in case of error or can we still use the current behaviour ?
>> Yes, by simply not enabling the functionality. By default it is not enabled.

>
> OK that's fine. You know how I'm attached to keep backwards
> compatibility :-)

Sure thing. ;)

Best regards,

                        Krzysztof Olêdzki Received on 2009/12/10 19:17