Thanks Eric for the comments. Please refer to my incline answers.
Thanks,
John
On 24/06/2017, 12:58 AM, "Eric Friedrich (efriedri)" <efrie...@cisco.com> wrote:
Thanks John-
A few more questions:
- Are there any extensions to the Track class needed here?
[John] I am planning to add a plugin stats hash map in StatTrack to include
statistics for all plugins.
- 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?
[John] Because the ResultType and ResultDetails in Track are enum, it
appears that we have to manually add new types. So here I will add a new
ResultType of “PLGN” to indicate a request is processed by any plugin (if finer
grain is required, each plugin could add its own ResultType to the enum), and
for ResultDetails, when implementing a plugin, corresponding types could be
added to the enum.
- 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)?
[John] Yes, with the plugin stats hash map in StatTrack, each plugin could
create its own plugin specific statistics counters.
- 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?
[John] Yes, the plugin will have following prototype methods:
loadConfig(); // called when CRConfig is updated
selectCaches(); // called in TrafficRouter::selectCaches() hooks
createStatsInstance(); // called in StateTrack::initialize()
Also just for information because I think its an important point- such a
plugin would be statically compiled into the TR “jar"
[John] Yes, this is true.
—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
>
