squid-3.5.5-1.el6.x86_64
CentOS 6.6
This looks like a bug in Squid v3 or a difference from 2.7. Our monitor couldn't be simpler. It requests the SAME URL twice (identical in every way, same hostname too), and expects the 2nd response to contain the X-Squid hit header. If it does not, then Squid has some sort of race condition going on its code.
I just reproduced this by hand, using an HTTP sniffer tool. I requested the same URL twice, with about a 0.25 second delay between fetches, and the 2nd attempt was ALSO A MISS. Then I waited 1 second and tried a 3rd time, and it was FINALLY a hit.
Squid v3 seems to have changed the way it stores objects. Maybe it is doing some sort of "asynchronous" background store now, so if you send in sequential requests without a delay between, it may not actually have finished storing it yet, so it doesn't report a "hit". Meaning, the first "miss" response may have fired off a thread to store the object, and not doing it in the main thread anymore like in v2, if you get my meaning.
For the Squid dev team, here are the headers we are sending back from the origin App VIP:
Accept-Ranges: none
Access-Control-Allow-Origin: *
Cache-Control: max-age=300
Connection: close
Content-Length: 403
Content-Type: image/jpeg
Date: Tue, 28 Jul 2015 17:25:36 GMT
Expires: Tue, 28 Jul 2015 17:30:36 GMT
Last-Modified: Mon, 11 Jun 2012 04:25:18 GMT
Server: Apache/2.2.26 (Unix)
This should very much be cached right away and it's a simple tiny image.
One thing we also notice is this only occurs doing load, meaning when we have production load traffic this fails, but if there is no other connections to the box, no other queries, this does not fail. Is it possible that squid is ejecting this that fast or is there another possibility here? Not sure what other data I can provide but will if asked.
Thanks
Tory
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
