[squid-users] "Valid document was not found in the cache" forwarded to clients

Corentin Delcourt codl at codl.fr
Fri Feb 20 14:28:51 UTC 2015


On 20/02/15 13:29, Amos Jeffries wrote:
> On 20/02/2015 10:55 p.m., Corentin Delcourt wrote:
>> I run two squid servers, siblings with each other, let's call them A and
>> B. When clients send requests to A, and A thinks B has the resource
>> cached, but in reality B doesn't,
> Use HTCP protocol between the peers, far less false positives than ICP
> or digest.
Will do, thanks for the tip.
>> the client will get a 504 error with
>> the message: “Valid document was not found in the cache and
>> ‘only-if-cached’ directive was specified.” Vice versa if clients send
>> requests to B.
>>
>> I believe that A should catch this error and fetch the resource
>> directly, but instead it forwards it to the client, and I cannot figure
>> out why. I am not using allow-miss.
> It should be but there are conditions to that:
>
> * another source of the URL is actually accessible (think IPv6-only
> websites, routing outages, DNS lookup failures, Path-MTU failures,
> traffic blackholes, etc)
If I re-send a failing request with Cache-Control: no-cache, or if I 
remove the cache_peer directive, I don't get any errors at all so it 
doesn't seem like this is the problem here.
> * there is time remaining within the forward_timeout for the alterative
> route to be contacted. If the timeout occurs the last error state
> encountered will be reported, if there is no earlier error the timeout
> itself is mentioned.
I believe the default timeout is 4 minutes? I set it explicitely to 10 
minutes, and forward-max-tries to 25 for good measure, and requests are 
still failing within hundreds of milliseconds so I don't think this is 
related.
> * the 504 is not being cached. That error response is one which is
> allowed to be cached by proxies if it gets delivered with cacheability
> headers. NP: It could be cached and delivered by either proxy, so even
> coming from the other one *it* may still have been cached and what
> caused the "HIT" to be identified.
I don't think the error is being served from cache. If I look at the 
access logs for both machines I see:

1424437827.131	6 127.0.0.1 	TCP_MISS/504		4913	GET http://example.net/ - SIBLING_HIT/10.0.1.2	text/html

… on A and

1424437827.882	0 10.0.1.1	TCP_MISS/504		4801	GET http://example.net/ - HIER_NONE/- 		text/html

… on B, 10.0.1.1 being A and 10.0.1.2 being B.
>> What confuses me even more is that this didn't happen a month ago, with
>> the same setup.
> ... what version of Squid?
> ... and is it the same setup AND version(s) of Squid from a month ago?
I'm running Squid 3.5.2 on both servers. I was running 3.5.1 on both a 
week ago and observing the same problem.

I can't say for sure which version I was running before this started 
happening, but I believe it was 3.4.8 on one machine and 3.4.10 on the 
other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150220/8c7db2ad/attachment.html>


More information about the squid-users mailing list