[ http://jira.jboss.com/jira/browse/JBCACHE-1305?page=comments#action_12418804 ] Manik Surtani commented on JBCACHE-1305: ---------------------------------------- Currently there are 2 JMX aspects to JBoss Cache. 1. The first is the CacheJmxWrapper which is a control interface that allows execution of certain cache methods via JMX, primarily for integration with other JBoss components. This may be deprecated in future. 2. The second aspect is about exposing cache statistics via JMX. Currently (in 2.X), if ExposeManagementStatistics is true in the configuration, the following happens: * A CacheMgmtInterceptor is added to the interceptor chain to capture hit and miss ratio. * All other interceptors start capturing statistics for their specific aspects. * All interceptors (as they implement the InterceptorMBean interface) are registered in the MBean Server and statistics can be read from them. This JIRA should really focus on the 2nd aspect since the first one may be deprecated in future and removed. The 2nd aspect really focuses on statistics and JMX is the correct channel for exposing statistics. My thoughts on improving the way we collect and expose statistics: * Some interceptors exposing statistics is fine, and a good thing - e.g., the CacheMgmtInterceptor, TxInterceptor. * Other interceptors' statistics are better collected elsewhere - e.g., replication stats should really be collected in the RpcManager and not the ReplicationInterceptor. * Other components may also expose useful statistics - e.g., LockManager exposing average wait times to acquire locks, most frequently contended Fqns, etc. To enable all of these, I think implementing an MBean interface will be a problem. Instead of implementing MBean interfaces, I think all components that wish to expose JMX information should be annotated as @MBean, similar to the way JGroups does this. (See the @MBean annotation in JGroups). To actually register the MBeans, an MBeanRegistryHelper can be added to the component registry as a bootstrap component, and this component, in its @Start method will look through all other components registered in the ComponentRegistry for anything annotated as @MBeans and register them accordingly. In @Stop, it would un-register them. The same MBeanRegistryHelper can also be used to register the CacheJmxWrapper, which is currently registered manually (not by a dedicated component in the CR). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCACHE-1305?page=com.atlassian.jira.p... ] Manik Surtani commented on JBCACHE-1305: ---------------------------------------- Should also make sure anything registered to unregistered from JMX are done so in the proper lifecycle phases of STARTED and STOPPED. Note that JBCACHE-1369 removed all other cache states such as INSTANTIATED, CREATED, DESTROYED. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCACHE-1305?page=com.atlassian.jira.p... ] Mircea Markus resolved JBCACHE-1305. ------------------------------------ Resolution: Done annotations were 'borrowed' (copied) from JGroups. All the existing code was moved to annotations (all the XyzInterceptorMBean were removed). RpcManagerImpl was enhanced to expose management stats. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira