[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