Hey Martin, I think JMX is fine for experimenting and for testing, so long as the SIS library itself remains compact and doesn't induce or force this dependency on downstream consumers.
Thoughts? Cheers, Chris On Nov 26, 2012, at 9:53 PM, Martin Desruisseaux wrote: > Hello all > > Yesterday I added I feature that we didn't had before, which can be removed > from compilation if considered undesirable. We did not had previously any > monitoring tools about the state of a running instance of the library. We > found that it was sometime problematic, since it make very hard to diagnostic > problems on a server. I think there is numerous places where JMX MBeans could > be used. For example report how many objects are cached, provide an option to > clear the caches, detect if there is a problem in the running SIS instance > (e.g. a daemon thread which unexpectedly died), etc. > > So I added an experimental "Supervisor" MBean in the internal package. For > now it contains only one method, "warnings()", which report any problem > detected in the running SIS instance. The only problem reported at this time > is unexpected death of the daemon thread consuming the weak references queue, > but future versions could perform more extensive tests of SIS state. This > MBean can been seen in JConsole (i.e. if an application using SIS is > currently running, start "jconsole" in another window, select the application > in the proposed list, click on "MBeans", select "org.apache.sis". The > "warnings" operation can been seen). > > The inconvenient is that SIS has to register its MBean to the > PlatformMBeanServer (the same instance than the one managing the standard > ClassLoadingJMXBean, MemoryJMXBean, GarbageCollectionJMXBean, etc.), and I > have no idea if it put a significant burden. In particular I don't know if it > trigs JMX class loading that would normally not happen. In my few tests, I > didn't saw noticeable slowdown at startup time... > > Any though? > > Martin >
