[
https://issues.apache.org/jira/browse/TS-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049366#comment-15049366
]
ASF GitHub Bot commented on TS-3418:
------------------------------------
Github user jrushf1239k commented on the pull request:
https://github.com/apache/trafficserver/pull/359#issuecomment-163386805
Done, Thanks for the git help!
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: Tuesday, December 8, 2015 at 10:21 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)
We are almost there. To get the commits in the right order we can squash
commit 3 into commit 1 and remove the accidental changes to
lib/tsconfig/TsConfigSyntax.c. On your branch is would be something like this:
$ git fetch --all
$ git rebase -i origin/master
$ # in the interactive rebase move commit 3 into 2nd place and change
'pick' to 'squash'
Now the commits are in the right order and squashed. We can get rid of the
accidental changes now:
$ git rebase -i origin/master
$ # in the interactive rebase change 'pick' to 'edit' for commit 1
$ # now you are paused in the middle of the rebase
$ git show lib/tsconfig/TsConfigSyntax.c | patch -p1 -R
$ git commit -a --amend
$ git rebase --continue
And force push the result.
-
Reply to this email directly or view it on
GitHub<https://github.com/apache/trafficserver/pull/359#issuecomment-163112743>.
> 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)
