Susan Hinrichs created TS-3665:
----------------------------------
Summary: 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)