[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2384.
-------------------------------
Resolution: Fixed
Closing, since this looks resolved for now. Open a new bug if you want to put
this code back in for a future release.
> Regression in key-lookup code between 4.0.x and 4.1.x
> -----------------------------------------------------
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Reporter: Igor Galić
> Assignee: Phil Sorber
> Fix For: 4.1.2, 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial 388912
> header length 2480
> fragment type 1
> No of Alternates 1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial 388912
> header length 2480
> fragment type 1
> No of Alternates 1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these
> objects downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means
> that the existing objects on the disks will stay in place, but we won't be
> able to find them, because we are looking in the wrong place. As such we
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in
> 304s.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
