Exposing JBossCache Management Attributes
jerrygauth Oct 20, 2005 4:53 PMReference
http://jira.jboss.com/jira/browse/JBCACHE-56
Background
The intent of this issue is to provide common cache characteristics such as hit/miss ratio, read/write ratio, number of cached nodes and attributes, etc. The issue's comments provide an extensive list of cache characteristics that are considered desirable to expose. It's also proposed that this implementation expose cache notifications via JMX in addition to the current TreeCacheListener implementation.
Design Overview
The initial design focus is on how to incorporate this capability into JBossCache. Once the design work and initial implementation is complete, it should be possible to review the list of attributes to be monitored and incorporate them over time, expanding or contracting the list as appropriate. Initially, the implementation will focus on simple characteristics such as number of nodes, number of attributes, number of hits, number of misses, and number of puts.
Design Alternatives
The simplest approach would be to add code to TreeCache to capture the necessary statistics and then expose them through the TreeCacheMBean. This is already in place for ?number of nodes? and ?number of attributes.? The obvious disadvantages here are that TreeCache.java is already quite large and adding numerous new methods to the TreeCache MBean will further clutter it and make it difficult for users to readily locate relevant statistics.
An alternative approach here is to provide a new MBean named TreeCacheManagement MBean that will be used to expose the management statistics. This MBean will be similar to the existing TreeCacheView MBean; it will be an optional MBean that's dependent on and associated with a configured TreeCache service. The TreeCacheManagement MBean will have a reference to its associated TreeCache instance so it can easily access statistics that are exposed by the TreeCache such as Number of Nodes and Number of Attributes.
Providing a new MBean resolves the second disadvantage noted above; the current TreeCache MBean won't be cluttered with new methods. However the first disadvantage remains as the new logic to capture cache statistics will still need to be located in the TreeCache implementation. It will also be necessary to add public methods to the TreeCache to make the statistics available to the new MBean. This could probably be minimized by providing the statistics via a single method (e.g., by returning a collection or array) rather than using individual methods per statistic.
In order to minimize changes to the TreeCache class, it's possible to introduce a new interceptor named CacheMgmtInterceptor. This interceptor can be used to capture various statistics as it intercepts TreeCache methods. For example, any invocation of TreeCache.getKeyValueMethodLocal() would result in a hit or a miss, depending on whether the method returned a null value. In this case, it's transparent to the TreeCache implementation that hits and misses are being counted. The interceptor accumulates the statistics and provides methods for callers to access them. The new TreeCacheManagement MBean can obtain a reference to the interceptor via the interceptor chain exposed by the TreeCache MBean so the statistics will be accessible to the new MBean.
There are at least two potential problems with the interceptor approach. First, some statistics may not be accessible via interceptors. Fir example, if a desired statistic isn't the input or output of a method, interception probably won't be able to capture it. In this case, it will probably be necessary to introduce logic into TreeCache to expose the statistic It's not clear whether this applies to any of the statistics currently of interest; this will be determined as they're implemented in turn.
A second potential problem relates to modifying logic flow in TreeCache. For example, all lookups ultimately invoke the method identified by TreeCache.getKeyValueMethodLocal(). If this situation changes in the future, it may not be obvious to the developer modifying the code that this condition was a prerequisite for logic in the interceptor that ascertained hits and misses. If the logic were in-line in TreeCache, it would be much more obvious to someone modifying the implementation.
Users should have the ability to disable the statistics gathering implementation if they wish to do so. Since deployment of the TreeCacheManagement MBean is optional, they can easily prevent the MBean from being deployed. However the interceptor still needs to be excluded from the TreeCache interceptor chain. The interceptor chain is established when the TreeCache service is created; at this point the TreeCacheManagement MBean hasn't been created as it's dependent on the TreeCache MBean. Consequently it's not possible for the interceptor factory to detect the presence or absence of the TreeCacheManagement MBean and act accordingly. One possibility here would be for the TreeCacheManagement MBean to dynamically add the interceptor but it appears that the current intention of the TreeCache interceptor stack is to not support dynamic changes. A simpler alternative would be to add a boolean attribute to the TreeCache MBean configuration specifying whether statistics should be maintained. The interceptor factory can then ascertain whether to incorporate the management interceptor or not.
Design Proposal
My proposal is to use a new TreeCacheManagment MBean to expose statistics, beginning with simple ones such as hits and misses. I think it makes sense to introduce a new interceptor rather than add the logic directly to TreeCache. I would add a new configuration attribute to TreeCache so that the management interceptor can be enabled or disabled appropriately.
Thoughts, alternatives?
I'll follow up with further discussion on individual statistics to ensure that we have agreement on how they should be measured.
Jerry