[ https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831241#comment-13831241 ]
Vladyslav Bachynskyi commented on TS-2384: ------------------------------------------ Sure! > 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ć > Fix For: 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)