You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/05/20 21:20:01 UTC

[jira] [Commented] (TS-3622) Writer doing unbounded retries for write VC to be closed during read_while_writer scenario

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

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

Commit 1f1334530fe66feea9e4896cebf58d83ef10ff3e in trafficserver's branch refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1f13345 ]

[TS-3622]: Add a bound to read_while_writer retries with a config setting


> Writer doing unbounded retries for write VC to be closed during read_while_writer scenario
> ------------------------------------------------------------------------------------------
>
>                 Key: TS-3622
>                 URL: https://issues.apache.org/jira/browse/TS-3622
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Cache
>            Reporter: Sudheer Vinukonda
>            Assignee: Sudheer Vinukonda
>
> During read_while_writer scenario, writer checks if the write VC is closed or the first fragment is completed to try and obtain the write VC's mutex. The writer keeps retrying (unbounded) with 100 msec intervals until either of this occurs. Currently, these retries are unbounded and since they occur nested within the *proxy.config.http.cache.max_open_read_retries*, they sort of cancel out the *proxy.config.http.cache.max_open_read_retries* setting. Opening this jira to add a bound on the number of such internal retries and fall back to the *proxy.config.http.cache.max_open_read_retries*, in case, they hit the bound.



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