[
https://issues.apache.org/jira/browse/TS-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045316#comment-15045316
]
ASF GitHub Bot commented on TS-3418:
------------------------------------
Github user jrushf1239k commented on the pull request:
https://github.com/apache/trafficserver/pull/359#issuecomment-162602947
Hi James,
I've squashed several commits and cleaned up the history, I'll be more
descriptive in the future. Also, I found that I had left in some code for the
multi-site origin feature. I've removed this code and the branch only includes
the refactor for the secondary hash ring and it's regression tests. All
re-testing in my QA environment and regression tests are good.
Thanks
--
John J. Rushford
IPCDN Engineering
1400 Wewatta Street, Denver Colorado 80202
john_rushf...@cable.comcast.com
From: James Peach
<notificati...@github.com<mailto:notificati...@github.com>>
Reply-To: apache/trafficserver
<re...@reply.github.com<mailto:re...@reply.github.com>>
Date: Sunday, December 6, 2015 at 5:31 PM
To: apache/trafficserver
<trafficser...@noreply.github.com<mailto:trafficser...@noreply.github.com>>
Cc: John Rushford
<john_rushf...@cable.comcast.com<mailto:john_rushf...@cable.comcast.com>>
Subject: Re: [trafficserver] TS-3418: Second hash ring for consistently
hashed parent selection (#359)
Hi John. First, let's clean up the commit history on this branch.
* please squash the "clang format" and "updated comments" commits into
their respective previous commits.
* for each commit, the subject should be a short description like
TS-3418: what this commit does"
* for each commit, add a longer description in the commit message for
future generations. What are all the changes in this commit? Why are they
necessary? Try to include enough description for someone to understand what is
going on in the commit.
-
Reply to this email directly or view it on
GitHub<https://github.com/apache/trafficserver/pull/359#issuecomment-162380212>.
> 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)
