[jira] [Comment Edited] (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-tabpanelfocusedCommentId=13831412#comment-13831412
]
Vladyslav Bachynskyi edited comment on TS-2384 at 11/25/13 12:26 PM:
-
All looks good now!
Apache Traffic Server - traffic_server - 4.1.2 - (build # 102513 on Nov 25 2013
at 13:38:53)
Thanks!
was (Author: vlad.bach):
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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)
