[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571528#comment-14571528
]
Sudheer Vinukonda edited comment on TS-3661 at 6/3/15 7:36 PM:
---------------------------------------------------------------
With the offending commit from TS-3140 removed below are the logs. The final
response is stored against the client url and no request to origin even for the
initial 3xx response, just serve it directly out of cache.
{code}
1433358337.199 0 x.x.x.x TCP_MISS_REDIRECT/303 0 GET
http://whos.amung.us/cwidget/4s62rme9/007071fecc4e.png - DIRECT/whos.amung.us
text/html
1433358337.282 210 x.x.x.x TCP_MISS/200 1487 GET
http://widgets.amung.us/draw/?w=colored&n=1&c=007071fecc4e&p= -
DIRECT/widgets.amung.us image/png
1433358350.107 2 10.87.93.144 TCP_HIT/200 1470 GET
http://whos.amung.us/cwidget/4s62rme9/007071fecc4e.png - NONE/- image/png
{code}
was (Author: sudheerv):
With the offending commit from TS-3140 removed below are the logs. The final
response is stored against the client url and no request to origin even for the
initial 3xx response, just serve it directly out of cache.
{code}
1433358337.199 0 10.87.93.144 TCP_MISS_REDIRECT/303 0 GET
http://whos.amung.us/cwidget/4s62rme9/007071fecc4e.png - DIRECT/whos.amung.us
text/html
1433358337.282 210 10.87.93.144 TCP_MISS/200 1487 GET
http://widgets.amung.us/draw/?w=colored&n=1&c=007071fecc4e&p= -
DIRECT/widgets.amung.us image/png
1433358350.107 2 10.87.93.144 TCP_HIT/200 1470 GET
http://whos.amung.us/cwidget/4s62rme9/007071fecc4e.png - NONE/- image/png
{code}
> 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)
