RE: Joining squid-dev List

-----Original Message-----
From: Mark Nottingham [mailto:mnot_at_yahoo-inc.com]
Sent: Tuesday, May 18, 2010 12:12 AM
To: Cimic, Senad (Legal)
Cc: squid3_at_treenet.co.nz; squid-dev_at_squid-cache.org
Subject: Re: Joining squid-dev List

Hi,

I'm looking at the same issue in Squid 2.HEAD (fortuitously, one of my
users complained about this at the same time).

It seems like the root of this (at least in 2) is in neighbors.c's
peerAllowedToUse(), which tests request->flags.need_validation.

clientCacheHit's refreshcheck block sets it with this comment:

        /*
         * We hold a stale copy; it needs to be validated
         */
        /*
         * The 'need_validation' flag is used to prevent forwarding
         * loops between siblings. If our copy of the object is stale,
         * then we should probably only use parents for the validation
         * request. Otherwise two siblings could generate a loop if
         * both have a stale version of the object.
         */
        r->flags.need_validation = 1;

Is the code in Squid3 roughly the same?

I'm tempted to get rid of the need_validation flag, as there are other
ways that Squid does loop suppression (e.g., only-if-cached on peer
requests, icp_stale_hit). What do people think of this? Is this howyou
addressed it.

Squid3 code is roughly the same - it performs 2 checks that affect stale
resources: request->flags.refresh and request->flags.need_validation. I
added new directive that ignores these checks if it's set to on (it will
be set to off by default). I've tested this change for ICP and cache
digests, still need to test HTCP before submitting the patch...

Also, I'm mostly interested in the HTCP case, where I *believe* that
there's enough information sent in the request to avoid a forwarding
loop, as long as their refresh_patterns are the same.

As an aside to the Squid devs -- I was somewhat surprised to see the
HTCP refreshCheck being done on the HTCP server side, rather than the
client side; wouldn't it be better to have the freshness decision made
where it's going to be applied?

Cheers,

On 17/05/2010, at 11:19 PM, <senad.cimic_at_thomsonreuters.com>
<senad.cimic_at_thomsonreuters.com> wrote:

> Thank you Amos. Currently the new option can be set globally. I can
see
> some advantages of having it set on cache_peer per-peer basis - do you
> think that would be better option for this patch? I can look into
> changing it, shouldn't take much more effort...
>
> Thanks again,
> -Senad
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Saturday, May 15, 2010 6:09 AM
> To: squid-dev_at_squid-cache.org
> Subject: Re: Joining squid-dev List
>
> senad.cimic_at_thomsonreuters.com wrote:
>> Hi,
>>
>> I'm following directions at
>> http://www.squid-cache.org/Support/mailing-lists.dyn in joining this
>> list... My main motivation is to submit a patch for the minor changes
> I
>> made to the squid source described below:
>>
>> We're in the process of implementing squid 3.1.1 version for reverse
>> proxying. The issue we ran into is related to running a cluster of
>> Squids in sibling mode. Problem was that for stale (cached but
> expired)
>> resources Squids always go to the backend servers to verify freshness
>> instead of contacting their sibling Squids (this was the case for
ICP,
>> HTCP, and cache digests).
>>
>> Changes I made include adding new squid.conf directive (on|off
option)
>> that makes this behavior configurable. By default, it will behave as
> it
>> is in current Squid version, but if turned on it will verify
freshness
>> of stale resources with its siblings (ICP, HTCP, and cache digests)
>> prior to contacting backend servers.
>>
>> I will work on re-formatting changed code to match Squid3 coding
>> standards and will afterwards follow the process to submit patch
>> request.
>>
>> Thanks,
>> Senad
>
> Greetings and Welcome Senad,
>
> I look forward to seeing the patch when it comes through. Are you
> looking at an option that can be set on cache_peer per-peer? or
> globally?
>
> FYI, Some administrative details to be aware of:
>
> There is about 2 months to go before 3.2 goes into beta. I'm hoping
> for July 1st, depending on the SMP project work. Config file features
> should aim to be done and approved by that point.
>
> 3.1 is officially closed to new features etc., though private patches

> are always a possibility.
>
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.3
>

--
Mark Nottingham       mnot_at_yahoo-inc.com