On Wed, Apr 1, 2009 at 11:03 PM, Brian J. Murrell <brian_at_interlinx.bc.ca> 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.
-- /kinkieReceived on Wed Apr 01 2009 - 21:49:53 MDT
This archive was generated by hypermail 2.2.0 : Thu Apr 02 2009 - 12:00:02 MDT