[
https://issues.apache.org/jira/browse/TS-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627093#comment-14627093
]
ASF subversion and git services commented on TS-3767:
-----------------------------------------------------
Commit af7cc27c0d78d212e4dc11ff6b35c56fae65e6e6 in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=af7cc27 ]
[TS-3767]: fix docs link.
> 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
> Assignee: 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.
> Also, refer TS-3768 for a future improvement on this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
