andrew@mira.net writes:
>Thanks for your fast reply.
>
>I take it the TCP_DENIED is a result of my squid deciding (from the aging
>rules) that an HTTP IMS is necessary, the result of which is not 304. Since
>we now know it is a cache miss, the request is denied. Is this correct?
Well, almost. I forget exactly which one is 'your squid', so I'll use
'A' and 'B'.
A user requests object O from cache A. Cache A sends an ICP query to its peer,
cache B.
Cache A has 'strict' refresh parameters, say for the request the third number
of the refresh_pattern line say that the max_age of the returned object must be
less than 1 day.
Cache B, on the other hand, has 'loose' refresh parameters, say a max_age of 5 days.
The ICP query does not convey these max_age requirements, but the HTTP request does.
So if the object O is 3 days old in cache B, then cache B returns an ICP_HIT. But
when the HTTP request comes along, A sends 'max_age=1' in its request and *this*
is what causes a cache miss at B, because the object O does not meet the requirements
of the request.
>I'm afraid I don't understand how the FAQ point:
>
> (1) Make sure all members have the same refresh_rules parameters
>
>can stop my squid reporting TCP_DENIED to a neighbor, given that ICP doesn't
>include aging information anyway.
>
>Would it make sense for a squid peer that gets a TCP_DENIED following a
>UDP_HIT _from_a_peer_ (but not a parent) to just ignore the failure and try
>the next peer/parent in its list?
It would, but the code isn't really structured that way unfortunately. To
implement that will require some significant changes. We are making those
changes to squid-1.2 and not to squid-1.1.
Duane W.
Received on Tue Jul 29 2003 - 13:15:42 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:22 MST