[ 
https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115639#comment-16115639
 ] 

ASF GitHub Bot commented on TC-90:
----------------------------------

Github user asfgit commented on the issue:

    https://github.com/apache/incubator-trafficcontrol/pull/318
  
    Can one of the admins verify this patch?


> 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)

Reply via email to