Re: [PATCH] StoreId with couple cosmetics in sync with trunk 12639

On 11/02/2013 9:18 a.m., Eliezer Croitoru wrote:
> On 2/8/2013 11:46 AM, Amos Jeffries wrote:
>> On 8/02/2013 5:23 a.m., Alex Rousskov wrote:
>>> On 02/06/2013 08:45 PM, Amos Jeffries wrote:
>>>> This audit round all appear to be documentation an debugs polish. Any
>>>> objection to me applying those changes and comitting?
>>> None from me, especially if you can remove code duplication that
>>> Eliezer
>>> cannot (the still unaddressed issue from the previous review).
>>>
>>>
>>> Thank you,
>>>
>>> Alex.
>>>
>>
>> All done, including the de-duplication, and applied as trunk rev.12655.
>> Please test the changes to redirect.cc are still working.
>>
>> Amos
> Thanks Amos,
>
> The code looks good and I managed to rebuild squid from trunk 12669.
>
> I will test it in the next few days to see if there are side effects.
>
> The next goals are:
> - enabling storeId for ICP.(async etc..)
> - enabling multi store-id key-val with first being used unless there
> is an storeId which already cached.
> - enabling storeId in REQMOD ICAP interface.(sending current storeId
> to the helper)
>
> Any other suggestions\request are welcome?

Portage of this bit to 3.3 ? That requires an alteration of the
redirect.cc code handling helper reply syntax since the OK/ERR/BH and
kv-pairs don't exit there.

storeId is in 3.4 now and we can hapilly leave it for release there if
you like. Just be aware I'm expecting that to only go stable late this year.

>
> I noticed another issue regarding squid with kids process:
> when used with two cache_dirs(rock+aufs) it uses two kids, is it
> suppose to be like that?

Yes Squid splits into a Disker kid which manages all the disk I/O
processes and a Worker which handles all the HTTP proxying and most
other tasks.

Amos
Received on Sun Feb 10 2013 - 22:57:33 MST