[
https://issues.apache.org/jira/browse/TS-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061394#comment-15061394
]
ASF GitHub Bot commented on TS-3418:
------------------------------------
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/359#issuecomment-165326498
> Note that FindParent() used to take a ParentConfigParams. Since the
lookup policy is now spread
> over the ParentRecord and the the config_params structures, it would be
cleaner to condense all
> this into a ParentSelectionPolicy object that is passed into FindParent.
I think this would help you
> separate the ParentSelectionStrategy from owning a ParentRecord pointer
too, since state that the
> strategy looks at would now be passed in.
Basically this boils down to
1. rename ``config_params`` to ``ParentSelectionPolicy``.
2. The ownership of the ``ParentSelectionPolicy`` is ambiguous since all
``ParentSelectionStrategy`` object have a pointer to it, but it is actually
only owned by the ``ParentConfigParams``. So keep it in ``ParentConfigParams``
(it doesn't need to me malloc'd), and pass it to ``ParentSelectionStrategy``
methods as an argument. ``ParentConfigParams `` now won't implement the
``ParentSelectionStrategy`1 interface, but it doesn't need to.
```
class ParentConfigParams : public ConfigInfo
{
// implementation of functions from ParentSelectionStrategy.
void selectParent(bool firstCall, ParentResult *result,
RequestData *rdata) {
return result->rec->selection_strategy->selectParent(policy,
firstCall, result, rdata);
}
private:
ParentSelectionPolicy policy;
};
```
> Second hash ring for consistently hashed parent selection
> ----------------------------------------------------------
>
> Key: TS-3418
> URL: https://issues.apache.org/jira/browse/TS-3418
> Project: Traffic Server
> Issue Type: New Feature
> Components: Parent Proxy
> Reporter: Leif Hedstrom
> Assignee: John Rushford
> Fix For: 6.1.0
>
> Time Spent: 336h
> Remaining Estimate: 0h
>
> It would be incredibly useful if we allowed for an (optional) second hash
> ring in the consistent hashing in parent selection. Imagine a setup where you
> have two set of parent proxies. A child would prefer to always use a parent
> <n> in ring <A> for a set of URLs, <X>. In the case of parent <n> not being
> available, instead of rehashing <X> to the surviving members of ring <A>, we
> could now hash the URLs to parent <m> in ring <B>. Upon failure there, we'd
> then go back and rehash on the primary ring again (<A>).
> This sounds complicated, but is simple in principle. Instead of immediately
> rehashing content upon a parent failure, we have a backup pool (potentially
> remote) of parents, that are likely to have the content. The idea is to
> minimize origin server traffic at all cost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
