[ https://issues.apache.org/jira/browse/TS-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14573056#comment-14573056 ]
Sudheer Vinukonda commented on TS-3665: --------------------------------------- Not exactly - TS-3585 calls *OSDNSLookup* which ultimately gets into CacheOpenReadHit/Miss etc and to me seemed to end in a bunch of additional/incorrect states. If you look at the code in *HttpTransact::DecideCacheLookup*, you will see that during redirects, all the cache read states are skipped and it ends up calling *LookupSkipOpenServer*. This path gets broken after TS-3585. > 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 > Fix For: 6.0.0 > > > 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)