[
https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125663#comment-16125663
]
ASF GitHub Bot commented on TC-90:
----------------------------------
Github user asfgit commented on the issue:
https://github.com/apache/incubator-trafficcontrol/pull/318
Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-traffic_ops-test-PR/17/
> 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
> Labels: cache_group, routing
>
> 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.4.14#64029)
