[
https://issues.apache.org/jira/browse/TS-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14717119#comment-14717119
]
ASF subversion and git services commented on TS-3622:
-----------------------------------------------------
Commit 2538a969943e76b0680c45e27b76a2fb912e3a7d in trafficserver's branch
refs/heads/5.3.x from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2538a96 ]
[TS-3622]: Add a bound to read_while_writer retries with a config setting
(cherry picked from commit 1f1334530fe66feea9e4896cebf58d83ef10ff3e)
> 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
> Fix For: 5.3.2, 6.0.0
>
>
> 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)
