[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571520#comment-14571520
]
Sudheer Vinukonda edited comment on TS-3661 at 6/3/15 7:25 PM:
---------------------------------------------------------------
Thanks to [~zwoop] for all the suggestions and follow up on this. The nice
thing about this finding is that, besides identifying the serious regression
(from TS-3140), this also helps in resolving TS-3652 (tbc), since it seems that
we always cache the final response against the original cache key (client url
or the modified one) anyway. We never cache with the key derived from
*Location* header, since the cache_sm for the original client key should be
still open and all reads/writes with *Location* key fail during redirect follow
attempts. Will open a separate jira to remove all the confusing code that
modifies the key to *Location* and tries to read/write during each redirect
follow attempt.
was (Author: sudheerv):
Thanks to [~zwoop] for all the suggestions and follow up on this. The nice
thing about this finding is that, besides identifying the break, this also
helps in resolving TS-3652 (tbc), since it seems that we always cache the final
response against the original cache key (client url or the modified one)
anyway. We never cache with the key derived from *Location* header, since the
cache_sm for the original client key should be still open and all reads/writes
with *Location* key fail during redirect follow attempts. Will open a separate
jira to remove all the confusing code that modifies the key to *Location* and
tries to read/write during each redirect follow attempt.
> 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*)
> 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)
