In java 5 update 6, or 1.5.0_06, or whatever goofy release naming scheme they’re using now, there’s a cool replacement for jconsole called “visualvm”. (On my mac, it didn’t come with the installed java, but it can easily be downloaded.) It cleans up jconsole a little bit, and merges in some of the other tools. You can monitor, take heap snapshots, and even do an extremely skeletal form of profiling.
We were tinkering with hooking up some of our servers' stats to monitoring tools by exposing them as “mbeans” across JMX (Java Management Xtreme), and someone suggested that it would be nice if the server’s configuration could be viewed and edited through the same console interface. So during some of the more lucid moments of my two-week-long cold, I tried hooking up a JMX interface to configgy to do just that.
It hasn’t gone extremely well.
Java – and JMX in particular – has reams of documentation, but most of it assumes you are a drooling infant or recent PHP convert. Quite a lot of it assumes you want to write your own replacement for jconsole or visualvm. Very little of it is written for someone who may just want to hook up management tools to an existing app or server. This seems strange when java is used so heavily for servers.
I finally figured out that the best interface for a tree of config nodes was
to create a tree of DynamicMBean objects which report their attributes as
being the attributes on the config node. This works pretty well. The interface
through visualvm won’t win any awards (and would make a UX person weep openly)
but functions basically the way you expect and lets you discover and edit
things in a straightforward way.
The fatal flaw in the UI is that if you add a new config item, visualvm doesn’t update the display tab to show the new attribute. (Jconsole behaves similarly.) At some level, it does appear to know to re-fetch the “mbeans” for the config tree, because I can see it doing that in the debugger. But it doesn’t use this information to update the display.
Looks like I have 2 options:
Register “mbeans” as the config nodes, and just live with the fact that they won’t be updated for new attributes. If you add a new attribute, you’ll have to disconnect visualvm and reconnect it to see everything.
Any time any config attribute changes, unregister and re-register the “mbeans” for config nodes. This makes visualvm destroy all open tabs to config nodes and rebuild the tree of config nodes in the left panel. You have to open the nodes back up to see the changes.
For now, I’m leaning toward #1 but both options make me sad. The punchline is this article I found while searching around on google, since I was convinced I must be doing it wrong:
http://forums.sun.com/thread.jspa?threadID=5218394
The thread summary seems to be: “We have documented a way for dynamic ‘mbeans’ to indicate that their attributes may change. We did not code our own tools to follow our own documentation so no existing tool uses this hint. Has our incompetence convinced you that you really want to do what you want to do, or are you eyeing that python book with a bit more interest now?”
Is there anyone out there that actually uses JMX for real?