Re: [PATCH] Support client connection annotation by helpers via clt_conn_id=ID

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Thu, 19 Jun 2014 21:07:42 +0300

On 06/16/2014 06:36 PM, Alex Rousskov wrote:
> On 06/15/2014 12:07 AM, Amos Jeffries wrote:
>> On 15/06/2014 4:58 a.m., Alex Rousskov wrote:
>>> On 06/11/2014 08:52 AM, Tsantilas Christos wrote:
>>>
>>>> I must also note that this patch adds an inconsistency. All annotation
>>>> key=values pairs received from helpers, accumulated to the existing key
>>>> notes values. The clt_conn_id=Id pair is always unique and replaces the
>>>> existing clt_conn_id=Id annotation pair.
>>>> We may want to make all annotations unique, or maybe implement a
>>>> configuration mechanism to define which annotations are overwriting
>>>> their previous values and which appending the new values.
>>>
>>> I suggest making all annotations unique (i.e., new values overwrite old
>>> ones) because helpers that want to accumulate annotation values can do
>>> that by returning old values along with new ones:
>>>
>>> received by helper: name=v1
>>> returned by helper: name=v1,v2
>>>
>>> Please note that the opposite does not work: If annotation values are
>>> always accumulated, a helper cannot overwrite/remove the old value.
>
>
>> Doing that would mean passing all existing annotations to every helper
>> lookup.
>
> Why would that mean the above?
>
> AFAICT, the helper should get only the annotations it needs. That need
> is helper-specific and, hence, is configurable via the various _extras
> and equivalent directives. That is already supported and does not need
> to change.
>
> Here is the overall sketch for supporting "unique annotations":
>
> 1. Send the helper the annotations it is configured to get
> (no changes here).
>
> 2. For each unique annotation key received from the helper,
> remove any old annotation(s) with the same key.
>
> 3. Store annotations received from the helper
> (no changes here).
>
> To support explicit annotation deletion, we can adjust #3 to skip
> key-value pairs with the value equal to '-'.

If there is not any objection I will implement this scenario.

Looks that this approach is the best and cover more cases than the
accumulated Notes values.
If someones need to accumulate Note values he can configure squid to
send old note value to helper and helper include it in its response.
This is simple.

If required in the future we can implement a configuration parameter
which configures one or more notes as always accumulated. For example:
   AccumulateHelperNotes status message

>
>
> HTH,
>
> Alex.
>
>
Received on Thu Jun 19 2014 - 18:08:01 MDT

This archive was generated by hypermail 2.2.0 : Sun Jun 22 2014 - 12:00:11 MDT