[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840619#comment-13840619 ] 

ASF subversion and git services commented on TS-2384:
-----------------------------------------------------

Commit 354fbc267e2bc2d522ac2d96a7b3b8b5b06fb438 in branch refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=354fbc2 ]

TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x

Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of uin32_t. Simplify methods because of this."

This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.

This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable 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)