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

Thanks for the pointers, we'll have a look. Le 21/07/2015 23:27, Jay Shaughnessy a écrit : > Right, you may find what you need is already in place, or you may find > that you can spend time on higher-level functions. In particular, see: > > MetricsService: > <T> Observable<T> findGaugeData(String tenantId, MetricId id, Long > start, Long end,Func1<Observable<DataPoint<Double>>, Observable<T>>... > funcs); > > Aggregate: > predefined functions. > > Here is an example snippen from > org.hawkular.alerts.external.metrics.Manager to gather multiple > aggregates in one call and determine the range: > > case range: { > Iterator<Double> iterator = > metrics.findGaugeData(tenantId, metricId, start, end, > Aggregate.Min, Aggregate.Max) > .toBlocking().toIterable().iterator(); > Double min = iterator.next(); > Double max = iterator.next(); > value = max - min; > break; > } > > > -Jay > > On 7/21/2015 10:43 AM, John Sanda wrote: >> 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 > > > _______________________________________________ > 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

And still in this case you need a way to supply them at runtime as opposed to compile them in. And this is what this work is about.