The goal of Aakarsh's work is not to implement min/max/avg, of course.
It's to let users plug in custom functions.
I've talked about min/max/avg because at some point we'll need to be
able to call builtin functions as well as user defined function, and it
would be nice to do it seamlessly.
Thank you for talking about RxJava. It makes me think we'll need to
consider which classes should be visible to user defined functions and
which shouldn't.
Le 21/07/2015 16:43, John Sanda a écrit :
Keep the following in mind. Since the core metrics API is now built
on
RxJava, function params and return types should probably be
rx.Observable. Some of the work described below may already be covered
by the work Jay did for HWKMETRICS-144 which involved adding min/max/avg
functions. To be honest, I think functions like min/max/avg are poor
candidates for some of the changes being discussed because they are so
simple. Here is our avg function,
Func1<Observable<DataPoint<Double>>, Observable<Double>>
Average =
data ->
MathObservable.averageDouble(data.map(DataPoint::getValue));
For other, more involved functions, I think we should look first at the
core operators in Rx.Observable and then maybe consider custom operators[1].
[1]
https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators
> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo(a)redhat.com
> <mailto:tsegismo@redhat.com>> wrote:
>
> Hi,
>
> I have looked at Aakarsh's repo:
>
https://github.com/Akki5/hawkular_plugin/
>
> It's a good start with an interface describing a doubles to double
> function, a classloader for implementation loading and a set of initial
> implementations.
>
> In order to integrate this work into Metrics, I think we should follow
> the following steps:
>
> =====
> #1 Change the contract
>
> Doubles to double works great for avg/min/max/... functions on gauge
> metrics. But we need to consider other metric types.
>
> Also, the interface should not only accept data point values, but whole
> data points. Because some functions need the timestamp to compute the
> result. % of up availability is a good example.
>
> And functions may return different types: Double, Long, AvailabilityType.
>
> #2 Update configuration options to let the user set a plugins directory
>
> Metrics doc needs will have to be updated.
>
> #3 Create a function repository for each metric type
>
> We can build on JDK's service loader + Aakarsh's classloader
> implementation.
>
> #4 Add builtin aggregate functions
>
> Extract existing Metrics code (min, max, avg, % of up avail, downtime
> duration) into builtin functions.
>
> #5 Document the process of implementing a pluggable function
>
> We need to think about function naming as well. Should we use a prefix
> to identify a builtin function?
> =====
>
> I will start another thread to discuss REST and Core API data query
> changes.
>
> Thoughts?
>
> Thanks,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev