Hi Dave, Thanks a lot. I took a look at the neustar geolocation provider PR at https://github.com/Comcast/traffic_control/pull/1229/files. This extends the geolocation provider to support multiple providers, which gives me some good ideas. But it does not seem to add extra statistics and logging. Anything else I might borrow from it?
Thanks, John On 24/06/2017, 6:12 AM, "Dave Neuman" <[email protected]> wrote: Have you taken a look at how we did the neustar geo location provider integration? That should give you some ideas. On Fri, Jun 23, 2017 at 10:58 AM, Eric Friedrich (efriedri) < [email protected]> wrote: > Thanks John- > A few more questions: > > - Are there any extensions to the Track class needed here? > > - Can we indicate in the access log how the plugins caused the request > to be routed? If a plugin wanted to add additional detail to a Track object > is that possible? > > - Can a plugin interact with the stats API at all (if we want to see > how many requests the plugin is serving or what the status of the > connection between plugin and external system is)? > > - I assume the plugin may need to have some context associated with it. > Do you have a prototype of what the callback made to the plugin will look > like? > > Also just for information because I think its an important point- such a > plugin would be statically compiled into the TR “jar" > > —Eric > > > > > On Jun 23, 2017, at 10:49 AM, John Shen (weifensh) <[email protected]> > wrote: > > > > Traffic Router currently support Coverage Zone File based routing and > Geolocation based routing. We are planning to add another type of routing > selection logic. Since this part of code will not be put into open source > code, we are considering how to integrate the new routing selection code > into current TR. > > > > One solution is to make Traffic Router support routing selection > plugins. Then we implement our new routing selection logic as a plugin, > which is still statically built into the TR package. Other types of new > routing selection plugins could also be integrated into TR easily. The plan > is to add several hooks in the method of: > > protected List<Cache> TrafficRouter::selectCaches(final Request > request, final DeliveryService ds, final Track track); > > > > There could be 4 possible hooks to be added: PRE_CZF_HOOK, > POST_CZF_HOOK, PRE_GEO_HOOK, and POST_GEO_HOOK. They will be processed > during different stages in TrafficRouter::selectCaches(). Plugins could be > registered in each hook. If there are multiple plugins in each hook, they > will be processed in the order of how they are registered. Any plugin > returning non-empty caches means a cache selection is successful for a > certain request, thus no further plugin or CZF/GEO based routing is needed > for the request. > > > > Any plugin will be created and registered during system initialization. > A possible point to do so is when ConfigHandler is initialized. And a > plugin would have following interfaces: > > loadConfig(); // called when CRConfig is updated > > selectCaches(); // called in TrafficRouter::selectCaches() hooks > > > > Please help to comment this proposal. Thanks. > > > > Best regards, > > John > > > >
