[
https://issues.apache.org/jira/browse/TS-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572972#comment-14572972
]
Sudheer Vinukonda commented on TS-3665:
---------------------------------------
Yes, but, the 3xx responses are not generally cacheable, so, the read always
fails (at least in my tests), so, the mentioned assert never triggers.
The only reason a 3xx would/should ever get stored into the cache is if the
final response (after exhausting all reattempts) is also a 3xx AND it is
cacheable. However, even in that case, the 3xx should get stored directly
against the original cache key (remapped client request url). So, anyway, you
look at it, the *intermediate* reads should always fail.
But, it may be possible that, there's a direct client request with the same url
as that of one of the intermediate Location headers of a different request that
is being 3xx redirect followed. In that case, I do see that it's possible that
the read might succeed.
So, if that's what you are running into, then, the ink_assert on cache_read_vc
should also be changed similar to the ink_assert I changed for cache_write_vc
in TS-3661. And of course, the old cache_read_vc should be closed to prevent a
leak as well.
> Redirect logic causing debug asserts and leaking cache_vc's
> -----------------------------------------------------------
>
> Key: TS-3665
> URL: https://issues.apache.org/jira/browse/TS-3665
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Reporter: Susan Hinrichs
>
> This is related to TS-3140 and TS-3661. I spent this morning reviewing the
> issue addressed by TS-3140 after the fixes for TS-3661 were put in place.
> TS-3140 addresses the issue when the 301 is in cache, but I'm seeing asserts
> for both 301's in cache and 301's not in cache.
> My first assert was line 109 in HttpCacheSM.cc line 109,
> ink_assert(cache_read_vc == NULL). I added a cache_sm.close_read() to the
> HttpTransact::SM_ACTION_REDIRECT_READ: case of HttpSM::handle_api_return.
> While only debug assert, if we ignore it we will reassign cache_read_vc
> without freeing the previous.
> I addressed this by adding cache_sm.close_read() to the
> SM_ACTION_REDIRECT_READ case of HttpSM::handle_api_return.
> My second assert is in HttpSM::do_cache_prepare_action (line 4446 of
> HttpSM.cc). Before the changes for TS-3661, it was expressing itself in
> SM_ACTION_CACHE_ISSUE_WRITE case of HttpSM::cache_write_state(). In this
> case, do_cache_prepare_action will open a new cache_write_vc overwriting the
> original and losing the cache_vc memory.
> The original fix to TS-3140 addressed this by adding a cache_sm.close_write
> in the SM_ACTION_REDIRECT_READ case of HttpSM::handle_api_return. But this
> caused problems of TS-3661 causing the originally selected cache key to be
> lost, but if you pass through this logic, I assume that the original cache
> write vc will be lost anyway. [~sudheerv] and [~zwoop] does this situation
> not happen in your redirect use cases? I'm afraid that I'm not following how
> the original cache key is preserved in the second cache open only if the
> first cache write open is not cleaned up.
> My test URLs are:
> curl -v --proxy localhost:80
> http://whos.amung.us/cwidget/4s62rme9/007071fecc4e.png
> and
> curl -v --proxy localhost:80 http://docs.trafficserver.apache.org
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
