[rhq-metrics] Possible implementation idea for pluggable aggregators

Thomas Segismont tsegismo at redhat.com
Fri Dec 19 17:18:12 UTC 2014


Long overdue reply, sorry.

Your proposal is certainly the most container-friendly solution.

Had we based rhq-metrics on another technology with a flat classpath 
paradigm, we could have use something as simple as the Service loader[1].

[1] http://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html


Le 03/12/2014 21:56, Heiko W.Rupp a écrit :
> Hey,
>
> so I have been thinking on how users can write their own aggregators and aggregation functions and deploy them in a pluggable way.
>
> As we are thinking about messaging for rhq.next anyway [1] I thought this could be done by forwarding data and/or requests to a message queue / topic and have listeners react on those messages.
> Being old-school, I decided to use MessageDrivenBeans - especially as Mazz has already created the necessary bits for running an ActiveMQ broker as subsystem in WildFly and also a ResourceAdapter [2]
>
> I've implemented two kinds of things so far (don't worry, all in a branch in my own repo :-):
>
> 1) forward all incoming data to a topic and have then MDBs work on them [3] - this could be used in alerting, where
> the alert engine just picks up those messages and works on them.
> Samples via MDB look like this [4]:
>
>
>
> @MessageDriven(activationConfig = {
>      @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
>      @ActivationConfigProperty(propertyName = "destination", propertyValue = "metrics")
> }
> )
> @SuppressWarnings("unused")
> public class MaxMdb extends AbstractMetricDrivenMDB {
>
>      @Override
>      void workOn(List<RawNumericMetric> metrics) {
> /// do work here
>    }
> }
>
> I guess the activation config could even go into the abstract superclass
>
>
> 2) Adhoc aggregation worker
> Those are MDBs that are triggered by this code block in the MetricHandler [5]
>
>
>    @GET
>      @Path("/metrics/{agg}/{id}")
>      public void getAggregate(@Suspended final AsyncResponse asyncResponse,
>                                   @PathParam("agg")String name, @PathParam("id")String id) throws Exception {
>
>          BasicMessage msg = new BasicMessage(id);
>          Map<String,String> headers = new HashMap<>();
>          headers.put("function",name);
>
>          aggregationProcessor.sendAndListen(msg,
>              new BasicMessageListener<BasicMessage>() {
>                  @Override
>                  protected void onBasicMessage(BasicMessage basicMessage) {
>    /// Work on results - e.g  asyncResponse.resume();
>
> Basically the name of the aggregation function is passed as path parameter and
> added as a header field for messaging
>
> The MDB code would then look like this [6]:
>
>
> @MessageDriven(activationConfig = {
>      @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
>      @ActivationConfigProperty(propertyName = "destination", propertyValue = "aggregationTask"),
>      @ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "function = 'invert'")
> }
> )
> @SuppressWarnings("unused")
> public class InvertAdHocAggregator extends AbstractAggregationWorkerMDB {
>
>      @Override
>      BasicMessage work(BasicMessage msg) {
>   /// compute the result here
>    }
> }
>
> The most interesting part here is
>
> @ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "function = 'invert'")
>
> where the propertyValue defines a selector that determines what messages can reach this MDB.
>
> So with above MetricHandler code
>
> GET /metrics/bla/123  would not trigger this MDB but
> GET /metrics/invert/123 would do.
>
> I am not saying we should adopt this way for user definable aggregations; the beauties are though
> - each MDB can just be deployed into the server as its own jar file
> - processing can easily be distributed onto many compute nodes because of the message bus.
>
> [1] https://developer.jboss.org/en/rhq/blog/2014/08/14/thoughts-on-rhqnext-server-architecture
> [2] http://management-platform.blogspot.de/2014/11/messaging-infrastructure-using-activemq.html
> [3] https://github.com/pilhuhn/rhq-metrics/blob/msg-integration/rest-servlet/src/main/java/org/rhq/metrics/restServlet/MetricHandler.java#L123
> [4] https://github.com/pilhuhn/rhq-metrics/blob/msg-integration/clients/metric-driven-mdb/src/main/java/org/rhq/metrics/clients/metricDrivenMDB/MaxMdb.java
> [5] https://github.com/pilhuhn/rhq-metrics/blob/msg-integration/rest-servlet/src/main/java/org/rhq/metrics/restServlet/MetricHandler.java#L251
> [6] https://github.com/pilhuhn/rhq-metrics/blob/msg-integration/clients/metric-driven-mdb/src/main/java/org/rhq/metrics/clients/metricDrivenMDB/adhoc/InvertAdHocAggregator.java
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>



More information about the rhq-devel mailing list