[
https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267354#comment-15267354
]
Leif Hedstrom commented on TS-4235:
-----------------------------------
Since no one has objected, I believe we can mark these as deprecated for 6.2.0.
> Deprecate fuzzy cache revalidation ?
> ------------------------------------
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to
> deprecate (for now) and later remove the fuzz logic. These configs are
> currently in place:
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT,
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other
> readers from the object anyways. So you are likely to benefit / use this only
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible
> that #2 improves, but in that case, I'd argue that if you allow it to serve
> stale, you are better off letting it expire and not "prematurely" revalidate
> the object.
> 4) It seems to cause confusing behavior as it is today (with default
> settings), e.g. anything with less than 240s TTL is likely to trip up and
> prematurely expire long before intended (this is why we added the
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default,
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz
> logic? It feels better to spend some time on adding more features to the
> fail_action feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
