[
https://issues.apache.org/jira/browse/TS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571412#comment-14571412
]
Sudheer Vinukonda edited comment on TS-3661 at 6/3/15 7:35 PM:
---------------------------------------------------------------
Logs without the fix:
{code}
1433296494.591 0 x.x.x.x TCP_MISS_REDIRECT/302 0 GET
http://www.amazon.com/gp/r.html?R=VVLFMI81YNMS&C=308E7DQYDUISH&H=TS2KZERKAKBATNLPGXSOZLMW6IOA&T=E&U=http%3A%2F%2Fimages.amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif
- DIRECT/www.amazon.com text/html
1433296496.462 0 x.x.x.x TCP_MISS_REDIRECT/302 0 GET
http://www.amazon.com/gp/r.html?R=VVLFMI81YNMS&C=308E7DQYDUISH&H=TS2KZERKAKBATNLPGXSOZLMW6IOA&T=E&U=http%3A%2F%2Fimages.amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif
- DIRECT/www.amazon.com text/html
{code}
Logs with the fix
{code}
1433353508.762 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
1433353508.848 218 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
1433353519.826 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
1433353519.828 133 x.x.x.x TCP_HIT/200 1470 GET
http://widgets.amung.us/draw/?w=colored&n=1&c=007071fecc4e&p= -
NONE/widgets.amung.us image/png
{code}
was (Author: sudheerv):
Logs without the fix:
{code}
1433296494.591 0 10.87.93.144 TCP_MISS_REDIRECT/302 0 GET
http://www.amazon.com/gp/r.html?R=VVLFMI81YNMS&C=308E7DQYDUISH&H=TS2KZERKAKBATNLPGXSOZLMW6IOA&T=E&U=http%3A%2F%2Fimages.amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif
- DIRECT/www.amazon.com text/html
1433296496.462 0 10.87.93.144 TCP_MISS_REDIRECT/302 0 GET
http://www.amazon.com/gp/r.html?R=VVLFMI81YNMS&C=308E7DQYDUISH&H=TS2KZERKAKBATNLPGXSOZLMW6IOA&T=E&U=http%3A%2F%2Fimages.amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif
- DIRECT/www.amazon.com text/html
{code}
Logs with the fix
{code}
1433353508.762 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
1433353508.848 218 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
1433353519.826 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
1433353519.828 133 10.87.93.144 TCP_HIT/200 1470 GET
http://widgets.amung.us/draw/?w=colored&n=1&c=007071fecc4e&p= -
NONE/widgets.amung.us 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)
