[
https://issues.apache.org/jira/browse/TS-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606962#comment-14606962
]
ASF subversion and git services commented on TS-3665:
-----------------------------------------------------
Commit 9031516b71ff5780d89af0ed4da536757b6ab2aa in trafficserver's branch
refs/heads/5.3.x from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9031516 ]
TS-3665: Update CHANGES
(cherry picked from commit 8d16cdbe0db48b508297cec6f1ffc8e2cb9a6106)
Conflicts:
CHANGES
> 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
> Assignee: Susan Hinrichs
> Fix For: 5.3.1, 6.0.0
>
> Attachments: ts-3665-2.diff, ts-3665.diff
>
>
> 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)
