[
https://issues.apache.org/jira/browse/TS-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212304#comment-15212304
]
John Rushford commented on TS-4287:
-----------------------------------
[~zwoop], [~psudaemon], [~amc], [~jamespeach], [~bcall]
As discussed on the PR call, I changed from using 'dead server retry' to
'unavailable server retry'.
In parent.config, for each individual rule when the parents are origin servers,
you can enabled simple_retry, unavailible_retry or both.
In HttpTransact::handle_response_from_parent() the response code returned from
a parent origin server is checked. If it is a 404 then the transaction is
retried by calling the ParentSelection API nextParent() function. If the
response matches a 5xx code defined in parent.config for unavailable retries
(503 by default) the parent is first marked down by calling the parentSelection
markParentDown() function followed by calling the nextParent() function.
We're using this at Comcast and it seems to work quite well. Let me know what
you think about these changes.
> Add a simple and unavailable server retry feature to Parent Selection.
> ----------------------------------------------------------------------
>
> Key: TS-4287
> URL: https://issues.apache.org/jira/browse/TS-4287
> Project: Traffic Server
> Issue Type: New Feature
> Components: Parent Proxy
> Reporter: John Rushford
> Assignee: John Rushford
> Fix For: 6.2.0
>
>
> Parent Selection now supports the use of origin servers in the parent list.
> It would be useful to add a simple retry feature that would try another
> parent when a 404 response is received for content that may not be available
> on one origin but may be available on another parent origin in the parent
> list. This can happen when packagers are pushing live video chunks to
> multiple origins and a request comes into an origin that may not yet have
> received the requested file.
> It would also be useful to mark a parent origin down and retry a request
> using another parent origin if a 503 unavailable response is received or if
> some other other application 5xx response were received.
> A pull request will follow this ticket that adds the following configuration
> parameters to parent.config and that implements the retry functionality.
> The following new configuration parameters are available in parent.config
> when parent_is_proxy is false (parent origin):
> 'parent_retry', 'unavailable_server_retry_responses',
> 'max_simple_retries', and 'max_unavailable_server_retries'.
> 'parent_retry' - May be set to the value: 'simple_retry',
> 'unavailable_server_retry', or 'both'. parent_retry is disabled by default
> and may only be enabled with one of these values when 'parent_is_proxy' is
> false (parent origin).
> if 'parent_retry' is set to 'simple_retry' another parent will be retried
> when a 404 response is received from the parent origin. By default only one
> retry will be attempted for a 404 response but this may be increased from 1
> to 5 with 'max_simple_retries' parameter.
> if 'parent_retry' is set to 'unavailable_server_retry' and a response is
> received that is contained in a configurable list of response codes (503 by
> default), the parent that returned the code is marked down and another parent
> is retried. By default only one retry will be attempted but his may be
> increased from 1 to 5 using the 'max_unavailable_server_retries'
> configuration parameter.
> 'unavailable_server_retry_responses' is an optional comma separated list of
> response codes that may be configured to trigger a unavailable_server_retry
> when 'parent_retry' is set to 'unavailable_server_retry'. If not specified
> in the parent.config, the default response code is 503.
> If 'parent_retry' is set to 'both' then both simple_retry and
> unavailable_server_retry are enabled for this list of parents.
> 'max_simple_retries' is set to 1 by default but may be increased within the
> range 1 to 5.
> 'max_unavailable_server_retries' is set to 1 by default but may be increased
> within the range 1 to 5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
