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.

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