[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831412#comment-13831412
]
Vladyslav Bachynskyi commented on TS-2384:
--
All looks good now!
Apache Traffic Server - traffic_server - 4.1.2 - (build # 102513 on Nov 25 2013
at 13:38:53)
> 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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831231#comment-13831231
]
Igor Galić commented on TS-2384:
[~vlad.bach], do you think you could test the 4.1.x branch for us before we
attempt another 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ć
> 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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831115#comment-13831115
]
ASF subversion and git services commented on TS-2384:
-
Commit a90c877e8eb76d92f9ddfdf510a90c32a4ab6478 in branch refs/heads/4.1.x from
[~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a90c877 ]
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ć
> 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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830603#comment-13830603
]
Vlad commented on TS-2384:
--
Alan,
yes I'm run instances from different directories. But, to be sure, I've also
tried to install 4.1.1 over 4.0.1 - got same effect.
> 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_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830350#comment-13830350
]
Alan M. Carroll commented on TS-2384:
-
Hmmm. I am testing this on CentOS 2.6.32-358.23.2.el6.x86_64 and not seeing
this effect.
Just to check something, do you have the 4.0.1 version and the 4.1.1 version
installed in different directories? When you run and switch between them, do
you run them from those different directories?
> 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.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830237#comment-13830237
]
Vlad commented on TS-2384:
--
Hi,
Igor asked me to comment to this ticket, with info about my system and options
I've used to compile ATS.
Compile options:
./configure --prefix=/opt/trafficserver-4.1.1 --enable-experimental-plugins
--enable-reclaimable-freelist --with-user=ats --with-group=ats --enable-cppapi
hwloc-devel package installed.
System:
CentOS 6.4 - 2.6.32-358.18.1.el6.x86_64
My previous installation was under /opt/trafficserver-4.0.1, then I've compiled
4.1.1 to /opt/trafficserver-4.1.1 and copied all config files. When I've ran a
new ATS 4.1.1, I've found, that all previously cached objects are MISSed. But,
after switched back to 4.0.1, all objects was in cache and HITed again.
> 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.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830125#comment-13830125
]
Alan M. Carroll commented on TS-2384:
-
The varying "key" values are a red herring - those are in fact randomly
generated and so it is expected they would differ. For the first fragment in a
document (such as this) it is only the first key that matters.
> 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.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829650#comment-13829650
]
Leif Hedstrom commented on TS-2384:
---
I have some additions (I hope) for a regression test for this, I hope to have
it done tomorrow.
> 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.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829484#comment-13829484
]
Leif Hedstrom commented on TS-2384:
---
So the problem is a regression related to
c40c601c9167c4937f972daf7825821e527a5f67
> 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.1.2
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {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.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
