On Wed, Apr 1, 2009 at 11:03 PM, Brian J. Murrell <brian@xxxxxxxxxxxxxxx> wrote: > On Wed, 01 Apr 2009 05:37:04 -0400, Brian J. Murrell wrote: > > On Wed, 2009-04-01 at 05:37 -0400, Brian J. Murrell wrote: >> >> Why would such a static object be removed from the cache when there is >> so much space available. > > Here's an even more interesting example: > > 1238597521.686 RELEASE 00 000142CA 0F06582B61087E2A5C6BE02A200A9AA2 200 1238597521 1238558186 -1 text/plain 428970/9796 GET http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog > 1238597523.126 RELEASE 00 000142CB C261BFF5E1FAF1F044E6342EDB0C1215 200 1238597522 1238558186 -1 text/plain 428970/9796 GET http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog > 1238597532.285 RELEASE 00 000142CC FF533EA8A884F5E1270245CF1A270A73 200 1238597532 1238558186 -1 text/plain 428970/8348 GET http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog > > The same URL was fetched 3 times within 11 seconds and each time RELEASEd. It would be interesting to know whether the object had any explicit cacheeability information. Maybe it came with a very short Expires timeout, or each time it generates a different ETag. This trace would seem to indicate that squid decided that the object could be cached at access-time, but that it was stale when it tried to use it again. -- /kinkie
