[
https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886720#comment-15886720
]
ASF GitHub Bot commented on TC-90:
----------------------------------
GitHub user smalenfant opened a pull request:
https://github.com/apache/incubator-trafficcontrol/pull/318
[TC-90] Recovered changes for @elsloo
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/smalenfant/incubator-trafficcontrol jeff-tc-90
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-trafficcontrol/pull/318.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #318
----
commit 5cc44f8a1c6bc8364c2018a65b45b2e181e46277
Author: smalenfa <[email protected]>
Date: 2017-02-27T23:08:54Z
[TC-90] Recovered changes for @elsloo
----
> TR should check for closest cache group because using Maxmind Geolocation
> -------------------------------------------------------------------------
>
> Key: TC-90
> URL: https://issues.apache.org/jira/browse/TC-90
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Router
> Affects Versions: 1.8.0
> Reporter: Eric Friedrich
> Priority: Minor
>
> Problem Statement:
> If all caches in the primary cache group are unavailable, our goal is to
> provide a backup routing policy for RFC1918 clients.
> When client IP is an public Internet IP, the current backup policy is to
> assign the client to the geographically closest cache (Distance = MaxMind Geo
> Lat/Long - configured CG lat/long).
> With Jeff's proposed fix below, instead of going to the geolocation provider,
> TR would find the cache group closest to the CZF "hit" cache group.
> From Jeff Elsoo:
> There's a small logic gap in the existing algorithm around cache
> location selection and I think if we fix that (two line change), we
> should be better off all around. I think the only time we'd ever want
> to go to the geolocation provider is in the event of a miss on the
> CZF, so as long as we have a hit there, we should find the cache group
> closest to that hit location that has available caches. This would
> automatically provide the "backup" cache group concept, and has the
> added benefit of doing this selection dynamically based on the state
> of the CDN.
> See this to get an idea of what I mean: http://apaste.info/u3PQo
> Obviously we'd need to test this to ensure we don't break other functionality.
> dev@ Discussion Thread:
> https://lists.apache.org/thread.html/b033b3943c22a606370ad3981fa05fb0e7039161b88bbc035bc49b25@%3Cdev.trafficcontrol.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
