Commons Accumulator Implementations for Sum #209
Description
The ArpNetworking/Commons library now has implementations of different Accumulator patterns to sum Double values with different cost (memory/cpu) and precision. We already support these on the read side in the ISM KairosDb-Extensions. This issue is to support these in MAD; unfortunately, it's not as straight forward as MAD's Statistic and Calculator pattern were never intended to be parameterized. Below are a few options short of refactoring the entire model.
Option 1:
Pass the Accumulator to the Statistic constructor. This requires delaying Statistic creation and either passing the parameterization at creation time or creating the factory with it. Some challenges with this approach include: 1) How to select a statistic with a particular parameterization across pipelines (e.g. addressing StatisticFactory as a singleton), 2) How to configure parameterization globally and create statistics in pipelines.
Option 2:
Leave the Statistic as the unparameterized identifier and pass the parameterization to the Calculator. Calculators are created through Statististic's createCalculator method. The good news is that this only happens in Bucket, which can easily get configuration from AggregatorCongfiguration via Aggregator. The problem is that Calculator creation is done type-agnostically so parameterization of the construction is global for all Calculators.
Option 3:
If we register the Commons Accumulator with Guice based on configuration (an existing pattern) and then use Guice to construct the Accumulator instances each Accumulator could receive whatever injectable parameterization it requires. The problem is that you need to either 1) Plumb the Injector all the way to Bucket; OR 2) Create all the objects in the chain with Guice injecting them into one another as a chain. As a stop gap to full Guice we can use static injection in the Statistic on the created Calculator. This should work nicely since the Calculator's creation is essentially hidden behind a factory. It will need to be cleaned up in the future, but it also avoids the large refactoring of moving all in on Guice or the model refactorings described above.