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@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/d... Heiko

This actually like some interesting tooling that could be neat for other Jopr users too.

On 07/21/2009 04:56 PM, Heiko W.Rupp wrote: > Am 20.07.2009 um 17:48 schrieb Heiko W.Rupp: >> This actually like some interesting tooling that could be neat for >> other Jopr users too. > > RHQ/Jopr already has a plugin skeleton generator - see > http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/helper... > and especially > http://support.rhq-project.org/display/RHQ/Plugins+-+plugin+generator > > So this generator here can reuse some parts of the above generator or > on the other hand above generator could be extended to actually point > at some source code with MBeans and pull the information from there. > Then it would populate the plugin descriptor with the metrics > (descriptorMain.ftl) and also e.g. extend the implementation of the > Measurement and Operation Facets with code that pulls the data from > there or that invokes the operation. > > The later approach has the advantage that it could be reused by > other projects. But this would also mean that other projects would > need to use the same @MO/@MA annotations, which is unlikely. @MO and @MA are supposed to be part ofg JDK7: http://download.java.net/jdk7/docs/api/javax/management/ManagedAttribute.... So, if all depended on some jdk7-ish.jar that contained these annotations, that would solve the issue.