[rhq-metrics] Possible implementation idea for pluggable aggregators

Lukas Krejci lkrejci at redhat.com
Mon Jan 5 14:47:56 UTC 2015


AFAIK, jboss-modules supports ServiceLoader and so should Wildfly...

You just need to specify how you want the services treated when you declare 
your deps.

Not sure how this would work if your deps are dynamic / loaded at runtime 
without a module descriptor...

On Friday, December 19, 2014 18:18:12 Thomas Segismont wrote:
> 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-se
> > rver-architecture [2]
> > http://management-platform.blogspot.de/2014/11/messaging-infrastructure-u
> > sing-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/metri
> > c-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/metri
> > c-driven-mdb/src/main/java/org/rhq/metrics/clients/metricDrivenMDB/adhoc/I
> > nvertAdHocAggregator.java _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> 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