[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571762#comment-14571762
]
Bryan Call edited comment on TS-3661 at 6/3/15 10:26 PM:
---------------------------------------------------------
What is the final cache key? It sounds like you are using the cache key as the
original origin url and not updating it when it gets a redirect. This will
cause problems if the max age of the redirect is less then the final url or if
the redirect is not cacheable at all.
was (Author: bcall):
What is the final cache key? It sounds like you are using the cache key as the
original origin url and not updating it when it gets a redirect. This will
cause problems if the max age of the redirect are less then the final url or if
the redirect are not cacheable at all.
> 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
> Assignee: 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*)
> Update: While the above is *a* possible issue, the real reason for this
> regression is not directly related to the above problem. The above problem
> actually ends up helping the cause (so to speak), since it basically fails
> all open_writes with the new cache key (location based) during redirect
> follow.
> 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)
