What are some of the best practices in designing a JMX MBean? Any examples of ones you feel are especially useful?
+1
A:
The first thing that got me with my first JMX bean was return types - it's a lot easier if your methods return Strings - that way your client can easily display the response (I was mainly working with JConsole) - if you don't do this, you get things like com.mycompany.Response@xxxx as a response, which doesn't mean much :)
Rich
2009-03-31 13:51:13
I would modify this to suggest returning primitives plus Strings. That way you can log numerical values properly (no parsing required)
Brian Agnew
2009-03-31 14:12:49
+2
A:
Return absolute counts instead of rates. e.g. return total number of db commits, rather than deriving a rate.
By doing this, your clients can monitor and derive rates themselves, over whatever time periods they require. Perhaps more importantly, this protects the clients from missing surges in rates if they only connect infrequently.
Brian Agnew
2009-03-31 14:11:52
A:
Make sure that attributes have no side effects and are predictable in operation.
There is nothing worse than an innocent looking attribute that executes a time-consuming (or resource-consuming) operation. I've seen some humdingers in my time..
Fortyrunner
2009-03-31 21:57:00
Any examples of MBeans you feel are great examples of being well-designed?
jm04469
2009-04-03 21:16:01
I must confess to not using many of the standard beans. The ones I have implemented tend to be counters, tables of data etc. Simplicity really is the key. It depends on your audience as well. I design MBeans for tech support (not dev people) and so try not to make them too complicated!
Fortyrunner
2009-04-03 22:06:51
A:
Do not use JMX for logging so, for example, don't use an MBean function that returns details of all the connections since startup.
One should remember that JMX is meant for monitoring. Meaning - Display only data that is relevant to the current moment.
Ben
2009-11-30 12:24:58