[
https://issues.apache.org/jira/browse/TS-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627022#comment-14627022
]
ASF subversion and git services commented on TS-3767:
-----------------------------------------------------
Commit 3c57dc6e6f888d2fa6ca92bb2d6953016024f730 in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3c57dc6 ]
[TS-3767]: Add new config to limit the read-while-writer retries.
> More unbounded retries within read-while-writer breaking loop detection.
> ------------------------------------------------------------------------
>
> Key: TS-3767
> URL: https://issues.apache.org/jira/browse/TS-3767
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Reporter: Sudheer Vinukonda
> Labels: A
> Fix For: 6.1.0
>
>
> [~zwoop] noticed the loop detection (request to self) fails with default
> settings, when read-while-writer functionality is enabled. Upon further
> investigation, this seems to be caused by more cases of unbounded retries
> within read-while-writer (similar to TS-3622), which prevent reaching the
> loop detection point (currently, done after the cache lookup state).
> TS-3622 added a bound for read-while-writer in the case, where the writer
> lock is available, but, the first fragment is not downloaded yet, but, there
> are more cases which cause similar issues.
> Discussing with [~zwoop], we think we should add bounds in all such cases
> with configurable timer (duration) and configurable max number of retries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
