[squid-users] squid 4.x: decided: do not cache but share because the entry has been released

Alex Rousskov rousskov at measurement-factory.com
Sat Feb 23 22:16:25 UTC 2019


On 2/23/19 10:17 AM, Amos Jeffries wrote:
> On 24/02/19 5:33 am, David Touzeau wrote:
>> http.cc(982) haveParsedReplyHeaders: decided: do not cache but share
>> because the entry has been released; HTTP status 200

>> What “but share because the entry has been released” event means ?

> 'do not cache but share' means the reply may still be shared with other
> concurrent clients (eg. collapsed forwarding), but not to bother trying
> to cache it.

Correct. To participate in that sharing, those concurrent clients must
already have a lock on this entry. In other words, "concurrency" here is
determined by having guaranteed access to the Store entry rather than
just overlapping transaction lifetimes.


> 'entry has been released' means something else already caused the disk
> copy in cache to be removed or replaced.

Yes, and this is not limited to the old entries in the disk cache. Entry
"release" may happen even before the entry is earmarked for any of the
caches, and the release affects both disk and memory caches.


If you want to figure out why this response is not being cached, you may
need to figure out why the corresponding Store entry was marked for
release. Look for releaseRequest lines in the debugging cache.log that
match the same entry and try to determine why releaseRequest was called.

Alex.


More information about the squid-users mailing list