Re: cache-digest errors.

Karl Ferguson wrote:
>
> Hi Everyone.
>
> A fellow sibling and I are attempting to use cache-digest instead of ICP as
> an experiment and getting the following error on occasion:
>
> ERROR
> The requested URL could not be retrieved
>
> ----------------------------------------------------------------------------
> ----
>
> While trying to retrieve the URL:
> http://www.perfections.addr.com/jenny/ja25.jpg
>
> The following error was encountered:
>
> Forwarding Denied.
> This cache will not forward your request because it is trying to enforce a
> sibling relationship. Perhaps the client at 203.22.233.4 is a cache which
> has been misconfigured.
>
> ----------------------------------------------------------------------------
> ----
> Generated Mon, 05 Oct 1998 08:17:41 GMT by www.rts.com.au (Squid/2.0.RELEASE)
>
> We're both running 2.0-Release, and my sibling line for him is:
>
> cache_peer proxy.rts.com.au sibling 80 3130 weight=70 no-query
>
> As far as I can gather, our squids are setup correctly, we both allow
> eachother as siblings to share our caches (and that works fine) via icp.
> The logs at their end for this particular request is:
>
> 907575395.321 20 203.22.233.4 TCP_MISS/403 1100 GET
> http://www.perfections.addr.com/jenny/ja25.jpg - NONE/- -
>
> 907575395.321 RELEASE FFFFFFFF 403 -1 -1 -1 unknown
> -1/995 GET http://www.perfections.addr.com/jenny/ja25.jpg
>
> Now, aparantly the cache on rts.com.au is configured so as not to expire at
> all (in fact, his cache is still filling up and reference_age is a year) so
> we're wondering how this can be... This is happening more often, it
> wouldn't be so bad if it were occasional, but when errors start to come
> through as soon as you've taken out their "no-digest" line, we can't have
> that :-) (OTOH, it does WORK - requests do get sent though and reply
> perfectly as well).
>
> I think I've also already answered my own question by showing his logs - it
> seems that there's a false hit there (ok, there's lots of false digest hits
> - a _lot_ more noticable that a false icp hit anyway). They're also seeing
> the same on our cache here. I have a suggestion that we increase the
> frequency of the digest refreshing (I think it's set for 3600 seconds == 1
> hour) to something like 30 mins or less. But I have the feeling that this
> wouldn't make much of a difference.

I'd definitely say it's a false hit, and you don't have miss_access for
each-other. If you're going to do cache-digests (and even some ICP) you
probably want to allow it. There's a little give and take, but it all
balances out.

D

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
------END GEEK CODE BLOCK------