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) <weife...@cisco.com> 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 >
