[jira] [Commented] (TS-3729) cache_promote: Can crash / assert under conditions where origin is very slow

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640075#comment-14640075 ] 

ASF subversion and git services commented on TS-3729:
-----------------------------------------------------

Commit 3678a6e11b53520c35d06c7d8baed79f43f812e2 in trafficserver's branch refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3678a6e ]

TS-3729 cache_promote: defer TSHttpTxnServerRespNoStoreSet() to a global continuation, saves a possible race condition


> cache_promote: Can crash / assert under conditions where origin is very slow
> ----------------------------------------------------------------------------
>
>                 Key: TS-3729
>                 URL: https://issues.apache.org/jira/browse/TS-3729
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Plugins
>            Reporter: Leif Hedstrom
>            Assignee: Leif Hedstrom
>             Fix For: 6.1.0
>
>
> If the response from origin is very slow (> 60s), until ATS gets the headers, there's a window where cache_promote can assert and crash, when remap.config is reloaded on a live system. This is a similar problem to other places where we ended up having to ref-count the continuation and remap configuration.
> Since we defer the cache control until "read-response-header" due to TS-3426, this is an unfortunate (and temporary) problem. At the point where this hook needs to execute, we don't need access to the remap data or continuation, so my solution / proposal is that we just use a global continuation that is unrelated to the remap configs, and schedule it when this deferred cache control is needed. Later, we can then remove it completely.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)