[infinispan-dev] JOPR and managing Infinispan

[Manik Surtani]

Thanks for clarifying and adding detail, Heiko.  Have you thought  
about how best to generate the plugin descriptor from the  
@ManagedAttribute/@ManagedOperation annotations we have in Infinispan?

Cheers
Manik

On 20 Jul 2009, at 13:49, Heiko W.Rupp wrote:

> Hi Manik,
>
> Am 17.07.2009 um 21:26 schrieb Manik Surtani:
>
>> So while in Stuttgart presenting at the JUG there, I had a chance to
>> catch up with Heiko and discuss some details of upcoming management/
>> admin features for Infinispan.
>>
>> Immediately, we have a JOPR plugin that allows JOPR to manage
>> Infinispan instances.
>
> Note that the plugin and Jopr infrastructure can do much more than
> what we currently do with monitoring and allowing the user to run
> operations -- it is also possible to show configurations in the UI and
> to change the configuration of managed resources. Of course the
> plugin needs to support that.
>
>> Where this does need to improve though is that the JOPR plugin is
>> built with an XML definitions file that is hand written.
>>
>> * This should be generated as a part of the build process, by parsing
>> @ManagedAttribute and at ManagedOperation annotations in Infinispan.
>> * @ManagedAttribute needs to contain more information:
>> 	* Type.  JOPR has a concept of different types:
>> 		* informational types (labels that cannot be compared or measured),
>> e.g., Version number
>
> Those can actually be compared, but as Strings not be plotted. The  
> idea behind those
> so called "traits" is that those metrics (strings or numbers in  
> origin) only rarely change,
> so they are not stored on the server each time they are collected,  
> but only when they
> have changed.
>
>> 		* measurable types (numeric) that can be compared, plotted on a
>> graph, visualised in other ways, e.g., cache size
>> 		* two sub-types of measurable types: incrementing and decrementing,
>> e.g., number of commits
>
> There are actually 3 sub-types: inc, dec, dynamic. The first two  
> mean that the value is
> strictly monotonous increasing / decreasing e.g. number of Tx  
> committed. Jopr is able
> for those to automatically create per minute derivates.
> The last one (dynamic) means that values can "jump around".
>
>> 		* a timing-type, (represented in milliseconds as a long), e.g.,
>> average replication time
>
> This call time thing is actually a little different (but I probably  
> did not explain it well):
> This has some key like e.g. a URL or a method name of a Session Bean  
> and values
> of it are min/avg/max (3 values).
> This could perhaps be used to track replication times per channel or  
> such.
>
>> 	* This should be encapsulated as an enum and declared on each  
>> managed
>> attribute so JOPR can provide better visuals on these
>> 	* Some metrics need to be resettable to be meaningful, and the JOPR
>> plugin would need to reset these whenever the metrics are collected.
>> E.g., average replication time would need to be reset and  
>> recalculated
>> every time JOPR picks up the last average and plots it on a graph.
>> * @ManagedAttribute also needs to be able to describe units of
>> measurement
>> 	* JOPR has some allowed values here and these should be encapsulated
>> in an enum.  E.g., milliseconds.  Allows JOPR to display the
>> appropriate widgets based on the unit of data being displayed.
>
> The available units are declared here:
>
> http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/core/domain/src/main/java/org/rhq/core/domain/measurement/MeasurementUnits.java?view=log
>
>  Heiko
>
>

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org