Re: [PATCH] SMP SNMP

On 01/31/2011 10:18 PM, Amos Jeffries wrote:
> On 01/02/11 04:17, Tsantilas Christos wrote:
>> I am sending a new version of the patch.
>> Please my comments bellow for the fixes and my comments.
>>
>> Also I am including a patch for Ranges. The original patch which
>> included in squid-smp-snmp patch did not support 64bit range sizes which
>> required by the HttpRanges.
>>
>>
>> On 01/29/2011 03:06 AM, Amos Jeffries wrote:
>>> On 29/01/11 07:04, Tsantilas Christos wrote:
>>>> I am attaching the new version.
>>>>
>>>>
>>>> On 01/27/2011 05:10 PM, Amos Jeffries wrote:
> <snip>
>>>>
>>>>>
>>>>> * PERF_SYS_CURLRUEXP again is tricky to combine. best match would be a
>>>>> min() for oldest timestamp.
>>>>
>>>> Currently it is just return "0".
>>>>
>>>
>>> Oh I see.
>>>
>>> The meaning of LRU is "oldest timestamped object in cache, if LRU
>>> algorithm is used". The fact that the workers are not presenting the
>>> timestamp can be left for future fix. There is a bug open for that.
>>>
>>> What this SMP support needs to do is aggregate via a special filter
>>> equivalent to min() to retain the semantic oldest-object meaning. A
>>> special one is needed that works as unsigned and ignores '0' values.
>>
>> I just add your comment near the related source code.
>>
>>>
>>> As I understand it, if there are no values available from any worker we
>>> should return the SNMP no-data message instead of '0'.
>>
>> I did not found an quick/easy way to return no-data message (or an
>> example how to do it). I let it as is for now. Is it important?
>>
>
> The default switch case should handle it nicely if the hard-coded block
> is "#if 0"'d out of existence.

Already tested, plus some other options and it does not worked. I do not
remember the exact error, but it was something like "wrong value" on
snmpget, and bad behaviour on snmpwalk.

>
>
> In the range patch I think src/HttpHeaderRange.h typedef should be
> uint64_t for the S parameter. Once that is fixed and any side effects it
> can be commited.
>
> +1. Please commit when those two are resolved to your liking.
>
> Amos
Received on Mon Jan 31 2011 - 21:00:30 MST