Sudheer Vinukonda created TS-3661:
-------------------------------------
Summary: 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*)
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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
