Following information is currently being exposed through JMX:
| 1)RpcManager (replCount, replFailuresCount)
| 2)ActivationInterceptor (activation count)
| 3)CacheLoaderInterceptor (lods, misses)
| 4)CacheMngmtInterceptor (hits, missis, puts, eviction count, cache life in secs, avg read/write durration)
| 5)InvalidationInterceptor (number of invalidations)
| 6)PassivationInterceptor (number of passivations)
| 7) Txinterceptor (prepare, commit and rollback count)
|
| Is there any other information you would find useful for being exposed?
| ( Starting with 3.0 it is much easier to aggregate/expose thorough JMX - JBCACHE-1305 )
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169627#4169627
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169627
I've got this working.
I had to do some refactoring since the initialisation of the hierarchical
metadata was in the wrong place. It was in BasicKernelMetaDataRepository
while the removal was in AbstractScopeInfo.
I've moved it AbstractScopeInfo so it is symmetrical and we know whether
we created it.
It's brought up two issues which I'll raise bug reports for.
1) ScopingOverridingTestCase
This is failing because of the problem I suspected when taling to Kabir
about the issue that led to finding JBMICROCONT-330
i.e. a scoped controller context is sharing the same metadata
as one that should not be scoped.
2) We are not removing annotations from the mutable metadata when
we undeploy. I'm going to leave this failing in MutableMetaDataTestCase
Once these have been fixed, the kernel pom needs reverting so it
fails when there is a testfailure.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169621#4169621
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169621
this post is to sum up the IRC conversation about management requirements for JBM 2[1]
JBM 2 must be manageable:
- programmatically from the same VM using only a reference to MessagingServer
- remotely
In the remote case, we provide 2 different management API:
- Using JMX, the user can manage JBM from a JMX console (such as jconsole). To do so, he must have enable management in JBM configuration
- Using "management" messages on the Core API. He does not need to have enable JMX management in JBM configuration
In short, JBM 2 must be:
* always manageable programmatically and remotely using "management" messages
* is manageable remotely with JMX if and only if JMX management is enabled in JBM configuration
if JMX management is disabled in JBM configuration, no MBeanServer will be used. Managed resources will be looked up by our own management registry (e.g. a map with ObjectNames as key and MBean implementation as values)
[1] http://www.antwerkz.com/javabot/javabot/home/3/%23jbossmessaging/2/08/1/0...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169587#4169587
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169587