Martin, I think that this is a much needed capability for most applications, especially in SIS. Its sort of like a service within a service, right? I have seen this used in ElasticSearch (I'm not sure what its referred to in there exactly) and it seems to work really well. There is even a config file that allows you to turn the verbosity level up too which is a nice feature.
For SIS, I see this as being used in really long running processes like tile cache generation and maybe even image/vector mosaicking for future versions. Where do you see this being used first? You point out monitoring internal object caches but what about externally facing client caches? I've seen other java-based geo-apps totally puke on long running processes and I've had no clue what went wrong. I feel like what you're suggesting could help alleviate some of these pain points within SIS. Sorry for the ramble... Thanks, Adam 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 >
