[
https://issues.apache.org/jira/browse/TS-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365346#comment-15365346
]
John Rushford commented on TS-4642:
-----------------------------------
Leif this makes sense and we are aware of it and view it as a valuable feature.
Lets say you have one line in parent.config using a wild card dest_domain with
a list of parents. We found that a misbehaving origin can cause all mid-tier
parents to get marked down thereby affecting other remaps/delivery services so
that other origins could not be reached through the mid-tiers because the
mid-tiers are all marked down. So we use this "feature" by creating a
parent.config line for every delivery service / remap. Each line may use the
exact same list of parents but, at least one delivery service with a
misbehaving origin does not affect any other delivery service. So the
records.config the failure threshold is by delivery service in our environment.
So if you want parents marked down globally for all requests, you can use a
single parent.config line with a wildcard dest_domain. Do you want to talk
more about this?
> Parent host healths across multiple configurations is inefficient
> -----------------------------------------------------------------
>
> Key: TS-4642
> URL: https://issues.apache.org/jira/browse/TS-4642
> Project: Traffic Server
> Issue Type: Improvement
> Components: Parent Proxy
> Reporter: Leif Hedstrom
> Assignee: John Rushford
> Fix For: sometime
>
>
> It seems that if I have multiple config lines in parent.config, where I use
> the same list of parents for multiple rules, each such rules keeps it's own
> "health" status? That means that if you repeat a line 100 times, the number
> of "failures" until marked down is 100x more than what we configured in
> records.config.
> It seems that the health and failure counts should be per host, such that
> regardless of how many times I use each host in parent.config, it'll
> consistently use the settings from records.config.
> So, I'm not 100% sure this is how things works, but if they are not, I blame
> Phil.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
