Saturday, September 20, 2008
Created my first JMX MBeans today
I wanted to get started creating some MBeans so I did the Java Management Extensions (JMX) tutorial over on the Sun web site this afternoon.
I read some JMX books back in 2000 but no place I worked at since then has assigned me a task to implement an MBean before.
Recognizing that this might be a symptom of a chicken-and-egg problem, I decided to write a couple myself this afternoon.
It turned out not to be very hard.
The program I used as my guinea pig was an a text-based adventure program I created this year for exactly this sort of purpose. It has an object-oriented design, a simple input/execute command loop, a nice hierarchy of model objects that are all held together in a master model object called the GameModel.
So, I created GameModelMBean and PlayerMBean interfaces and implemented them on my GameModel and Player classes. Not very difficult at all. The interfaces just exposed a few read only properties.
I registered the two MBeans in the main method of my GameApp class.
Then I subclassed GameModel and my base class for the model objects, AObject, off of the NotificationBroadcasterSupport class. Not particularly elegant but it is not like I am ever going to sell this program. If I was trying to do a quality job, I would have chosen to implement the interface rather than subclassing my base class off a JMX class.
Then I updated the dies(), kills(), etc. methods of my ACharacter (abstract character) class to call the JMX sendNotification method it inherits from its NotificationBroadcasterSupport base class.
I wanted to expose all of my NPC objects as MBeans too. However, it seems like JMX just wants to be used for a single instance of a given class - not a bunch of them. There might be a way to get past this but for now that is okay with me.
As for getting JConsole to be able to monitor your application, that turns out to be easy as well. Simple add the -Dcom.sun.management.jmxremote JVM switch to your java command line that you use to invoke the JVM to run your main class.
Then run the jconsole command that comes with JDK 1.5 and later. The JVM will notice the application running locally on your computer and let you connect to it.
I have worked on a lot of applications that do some tasks. It would be nice to have a conventient way to keep track of how many times that tasks have been performed during the current run of the program.
Writing custom code to write the counters to a log, a file, or something else - possibly on demand or possibly just when it feels like it - is one possibility.
JMX offers a little more convenience and flexibility than these sort of hardcoded approaches.
Just as a logging library like Log4J lets you decide whether/how/where you want to log execution events by configuring how you run your application, JMX lets you decide if you want to run with it activated and then you connect to it with whatever type of JMX client you want.
JMX server support is built into lots of popular Java programs: Tomcat, JBoss, and so on. The Log4J library supports it too. Seeing so many big, powerful programs might lead a Java programmer to believe that JMX support is hard to add to an application. In reality, it is very easy to add and use.
I read some JMX books back in 2000 but no place I worked at since then has assigned me a task to implement an MBean before.
Recognizing that this might be a symptom of a chicken-and-egg problem, I decided to write a couple myself this afternoon.
It turned out not to be very hard.
The program I used as my guinea pig was an a text-based adventure program I created this year for exactly this sort of purpose. It has an object-oriented design, a simple input/execute command loop, a nice hierarchy of model objects that are all held together in a master model object called the GameModel.
So, I created GameModelMBean and PlayerMBean interfaces and implemented them on my GameModel and Player classes. Not very difficult at all. The interfaces just exposed a few read only properties.
I registered the two MBeans in the main method of my GameApp class.
Then I subclassed GameModel and my base class for the model objects, AObject, off of the NotificationBroadcasterSupport class. Not particularly elegant but it is not like I am ever going to sell this program. If I was trying to do a quality job, I would have chosen to implement the interface rather than subclassing my base class off a JMX class.
Then I updated the dies(), kills(), etc. methods of my ACharacter (abstract character) class to call the JMX sendNotification method it inherits from its NotificationBroadcasterSupport base class.
I wanted to expose all of my NPC objects as MBeans too. However, it seems like JMX just wants to be used for a single instance of a given class - not a bunch of them. There might be a way to get past this but for now that is okay with me.
As for getting JConsole to be able to monitor your application, that turns out to be easy as well. Simple add the -Dcom.sun.management.jmxremote JVM switch to your java command line that you use to invoke the JVM to run your main class.
Then run the jconsole command that comes with JDK 1.5 and later. The JVM will notice the application running locally on your computer and let you connect to it.
I have worked on a lot of applications that do some tasks. It would be nice to have a conventient way to keep track of how many times that tasks have been performed during the current run of the program.
Writing custom code to write the counters to a log, a file, or something else - possibly on demand or possibly just when it feels like it - is one possibility.
JMX offers a little more convenience and flexibility than these sort of hardcoded approaches.
Just as a logging library like Log4J lets you decide whether/how/where you want to log execution events by configuring how you run your application, JMX lets you decide if you want to run with it activated and then you connect to it with whatever type of JMX client you want.
JMX server support is built into lots of popular Java programs: Tomcat, JBoss, and so on. The Log4J library supports it too. Seeing so many big, powerful programs might lead a Java programmer to believe that JMX support is hard to add to an application. In reality, it is very easy to add and use.
Labels: java, monitoring, programming
