[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3661:
----------------------------------
Description:
During a 3xx redirect follow, the current TS implementation is that, it creates
a new cache key for the redirect follow request and stores the response against
the new cache key.
There's some logic in *HttpCacheSM::open_write* that's basically to check that
a txn is not stuck in a open_write loop.
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpCacheSM.cc#L289
The logic basically is to check the current *open_write_tries* for a given
*cache_sm* object against *proxy.config.http.cache.max_open_write_retries* and
against *redirection_tries* for that txn. The assumption here is that, we allow
atleast one *open_write_try* per redirect follow attempt.
{code}
if (open_write_tries > master_sm->redirection_tries &&
open_write_tries >
master_sm->t_state.http_config_param->max_cache_open_write_retries) {
master_sm->handleEvent(CACHE_EVENT_OPEN_WRITE_FAILED, (void
*)-ECACHE_DOC_BUSY);
return ACTION_RESULT_DONE;
}
{code}
However, the *open_write_tries counter* is incremented before checking the
condition, while *redirection_tries* is only incremented after receiving the
server response which is too late. This results in basically open_write_tries
being incremented ahead and would always fail the check (except, for a
non-default value (> 1) for *proxy.config.http.cache.max_open_write_retries*)
The issue seems to have been resulted due to the commits in TS-3140, which
close the original cache_sm before doing a redirect follow. Without this fix,
the original cache_sm (opened against the original client URL as the key) is
still open and is used to write the final (2xx) response from the origin.
However, closing the cache_sm before redirect follow with TS-3140 makes it so
that, the object never gets cached.
Fixing this should be very simple. Either reset the *open_write_tries* counter
in *cache_sm.close_write()* which is performed during the redirect follow
(before open_write with new cache_key), or adjust the logic a bit (e.g. swap
around the point at which the counters are incremented etc).
was:
During a 3xx redirect follow, the current TS implementation is that, it creates
a new cache key for the redirect follow request and stores the response against
the new cache key.
There's some logic in *HttpCacheSM::open_write* that's basically to check that
a txn is not stuck in a open_write loop.
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpCacheSM.cc#L289
The logic basically is to check the current *open_write_tries* for a given
*cache_sm* object against *proxy.config.http.cache.max_open_write_retries* and
against *redirection_tries* for that txn. The assumption here is that, we allow
atleast one *open_write_try* per redirect follow attempt.
{code}
if (open_write_tries > master_sm->redirection_tries &&
open_write_tries >
master_sm->t_state.http_config_param->max_cache_open_write_retries) {
master_sm->handleEvent(CACHE_EVENT_OPEN_WRITE_FAILED, (void
*)-ECACHE_DOC_BUSY);
return ACTION_RESULT_DONE;
}
{code}
However, the *open_write_tries counter* is incremented before checking the
condition, while *redirection_tries* is only incremented after receiving the
server response which is too late. This results in basically open_write_tries
being incremented ahead and would always fail the check (except, for a
non-default value (> 1) for *proxy.config.http.cache.max_open_write_retries*)
In 4.x, there's some additional logic with *secondary_cache_sm*, which performs
an additional lookup with the new object which succeeds. This seems to have
been cleaned up recently and exposed the above issue.
Fixing this should be very simple. Either reset the *open_write_tries* counter
in *cache_sm.close_write()* which is performed during the redirect follow
(before open_write with new cache_key), or adjust the logic a bit (e.g. swap
around the point at which the counters are incremented etc).
> cache broken during 3xx redirect follow response
> ------------------------------------------------
>
> Key: TS-3661
> URL: https://issues.apache.org/jira/browse/TS-3661
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Sudheer Vinukonda
>
> During a 3xx redirect follow, the current TS implementation is that, it
> creates a new cache key for the redirect follow request and stores the
> response against the new cache key.
> There's some logic in *HttpCacheSM::open_write* that's basically to check
> that a txn is not stuck in a open_write loop.
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpCacheSM.cc#L289
> The logic basically is to check the current *open_write_tries* for a given
> *cache_sm* object against *proxy.config.http.cache.max_open_write_retries*
> and against *redirection_tries* for that txn. The assumption here is that, we
> allow atleast one *open_write_try* per redirect follow attempt.
> {code}
> if (open_write_tries > master_sm->redirection_tries &&
> open_write_tries >
> master_sm->t_state.http_config_param->max_cache_open_write_retries) {
> master_sm->handleEvent(CACHE_EVENT_OPEN_WRITE_FAILED, (void
> *)-ECACHE_DOC_BUSY);
> return ACTION_RESULT_DONE;
> }
> {code}
> However, the *open_write_tries counter* is incremented before checking the
> condition, while *redirection_tries* is only incremented after receiving the
> server response which is too late. This results in basically open_write_tries
> being incremented ahead and would always fail the check (except, for a
> non-default value (> 1) for *proxy.config.http.cache.max_open_write_retries*)
> The issue seems to have been resulted due to the commits in TS-3140, which
> close the original cache_sm before doing a redirect follow. Without this fix,
> the original cache_sm (opened against the original client URL as the key) is
> still open and is used to write the final (2xx) response from the origin.
> However, closing the cache_sm before redirect follow with TS-3140 makes it so
> that, the object never gets cached.
> Fixing this should be very simple. Either reset the *open_write_tries*
> counter in *cache_sm.close_write()* which is performed during the redirect
> follow (before open_write with new cache_key), or adjust the logic a bit
> (e.g. swap around the point at which the counters are incremented etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
