You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Sudheer Vinukonda (JIRA)" <ji...@apache.org> on 2015/07/14 22:54:04 UTC

[jira] [Comment Edited] (TS-3767) More unbounded retries within read-while-writer breaking loop detection.

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

Sudheer Vinukonda edited comment on TS-3767 at 7/14/15 8:53 PM:
----------------------------------------------------------------

Per Leif's suggestion, will change the new setting name to *proxy.config.cache.read_whilewriter_retry.delay* to be inline with *proxy.config.cache.read_while_writer.max_retries*.


was (Author: sudheerv):
Per Leif's suggestion, will change the new setting name to *proxy.config.cache.read_whilewriter_retry_delay* to be inline with *proxy.config.cache.read_while_writer.max_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)