Hello Adam
Le 27/11/12 12:06, Adam Estrada a écrit :
Its sort of like a service within a service, right?
Kind of. JMX is a standard way to expose attributes and operations to an
external monitoring application like JConsole is a way similar to RMI.
In a web application, we would have an administrator page with buttons
for querying informations or perform maintenance operations. In JMX
there is only the programmatic interfaces and the visual widgets is left
to the external monitoring application.
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.
With JMX there would be no need for a config file, since changes in the
verbosity level could be operations. Actually the standard JDK already
provides a MBean for exactly that:
http://docs.oracle.com/javase/7/docs/api/java/lang/management/PlatformLoggingMXBean.html
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?
I see it used in Web Map Server, Web Coverage Server or any other kind
of servers. But this is true that mosaic creation and other long running
process are also targets.
You point out monitoring internal object caches but what about externally
facing client caches?
It depends what we call "client". On a webserver - browser architecture,
the browser side is more a JavaScript world in which case SIS would not
affect caching. On a desktop application using SIS locally, client cache
could also be monitored through JMX is desired. The application can
provide its own MBean. Or maybe the application would just rely on SIS
internal caching, in which case those caches would be visible be the SIS
MBeans.
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.
Yes this is exactly the point. One of our clients having various
web-applications from various projects, unconditionally reboot their
Tomcat servers every night for avoiding performance degradation and
other problems seen in "long" running processes (while one day is not
supposed to be long). This is the kind of situation that we would like
to avoid, and monitoring (together with logging and other approaches)
are one tools among other which may hopefully help.
Martin
