Help with Drools JON/RHQ plugin

Edson Tirelli etirelli at redhat.com
Thu Jul 14 14:39:31 UTC 2011


  I obviously forgot the attachments. Here you go.

   Edson

 ---
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.redhat.com

----- Original Message -----
From: "Edson Tirelli" <etirelli at redhat.com>
To: mazz at redhat.com
Cc: rhq-devel at lists.fedorahosted.org, "Mark Proctor" <mproctor at codehaus.org>
Sent: Thursday, July 14, 2011 10:34:36 AM
Subject: Re: Help with Drools JON/RHQ plugin


   John,

   Final problem with the Drools plugin for RHQ: operations. I added operations to the plugin descriptor as you can see here:

https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-rhq-plugin/src/main/resources/META-INF/rhq-plugin.xml

   Now, when I execute operations with parameters using jconsole, it works fine. See attached screenshot. When I try to execute the same operation with RHQ, with the same parameter, I get a NPException.

   The NPE seems to happen on the drools MBean code, but I don't see how calling an operation from jconsole is different from calling an operation from RHQ? Any pointers?

   Thanks
     Edson



 ---
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.redhat.com

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: rhq-devel at lists.fedorahosted.org
Sent: Tuesday, July 12, 2011 11:29:03 AM
Subject: Re: Help with Drools JON/RHQ plugin

[I'm forwarding this to the rhq-devel mailing list - this is a good tech 
discussion that should be made out in the open in the community]

Edson,

>  In the end I was able to test the plugin by nuking the installation and re-installing after each change, as you suggested.

Nice - can you tell me which H2 files you had to restore? Was it just 
one of those .db files or all of them?

>    My questions are:
>
> 1. I would like to change it to make the plugin a top level server instead of running inside the JMX Server. Is it possible? How can I do it?

You can probably do this. In your plugin descriptor, just mimic what the 
JMX descriptor has, tweeking as you need. In this case, you would not 
need any "<runs-inside>" metadata.

You can probably reuse the JMX server component as well. Or at least 
subclass it. Sounds like you want to override the discovery component so 
it only detect things that has your MBean in it. So I would investigate 
extending the JMX's plugin component "JMXDiscoveryComponent":

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java;hb=HEAD

Maybe write your own, or some how reuse the discover method:

org.rhq.plugins.jmx.JMXDiscoveryComponent.discoverResources(ResourceDiscoveryContext)

this method takes the process scan results (see the JMX plugin 
<process-scan> for what its looking for in the operating system process 
table - essentially it is looking for java executables). Sounds like you 
want to do a little extra - you want to find all java VMs that have your 
MBean in its platform MBean Server.

> 2. Related to above, I guess, how do I configure auto-discovery? My criteria is: any java process (JVM) that contains a DroolsManagementAgent MBean running should be discovered.

Right. See the JMXDiscoveryComponent class linked above for how you do 
the first part. The JMX plugin is configured via <process-scan> metadata 
to auto-discover java apps that are running. you'd then have to add your 
own discovery code to look for whatever specific info you want to 
further refine those results. In your case, you want to attach to that 
java VM, peek in its platform MBeanServer and see if your MBean exists. 
If it does, you'd return data for your discovered server. Otherwise, 
you'd return nothing to indicate you found nothing.

> 3. I was able to configure all the metrics I want to collect, but how to I collect configuration data? I.e., things that were configured in the application and that rarely change, but that I want to keep track of and store as an historical audit trail in JON/RHQ. E.g. "Event Processin Mode = stream", "Assert Behavior = identity", "Max threads = 10".

Sounds like you want what we call a metric "trait". A trait is like a 
metric but it can be any string (not just a double) and we track changes 
to them over time (under the Measuerment tab, there is a subtab, I think 
called "Traits"). It is assumed traits can change, but they change 
rarely (less so then dynamic measurement data like "number of DB 
connections" or "CPU utilization" or "free memory"). There are plenty of 
examples of trait definitions in many of our plugins. See the agent 
plugin or the jboss-as plugin or even the JMX plugin itself - look for 
<metric> definitions that have dataType="Trait" attributes. One example 
in the JMX plugin descriptor is:

          <metric displayName="Heap Initial Size"
                  property="{HeapMemoryUsage.init}"
                  displayType="summary"
                  dataType="trait"
                  description="The amount of heap that the Java virtual 
machine initially requests from the operating system"
                  units="bytes"/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jconsole.png
Type: image/png
Size: 123798 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110714/eecddd50/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RHQ.png
Type: image/png
Size: 230864 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110714/eecddd50/attachment-0003.png 


More information about the rhq-devel mailing list