Adventnet has released a new version of ManageEngine JMX Studio, a tool used to create management consoles over J2EE apps. The new version adds manageability for Apache Tomcat servlet containers, an out-of-the box JMX adaptor for TIBCO AMI, an Apache Axis SOAP adaptor, and enhanced security.
Check out MangeEngine JMX Studio
and the press release
So I know what JMX does, but I have to ask, is anyone building JMX enabled applications (aside from the app server vendors)?
I consult for a big securities trading company and we use it for all of our Java management and monitoring.
So, how much does this MBean code-generator cost? Considering how simple it is to wrap existing components in an MBean on a JMX-enabled server, I can see a company shelling out $2,000 for a fun GUI tool.
But this smells like one of those $50,000 + $12,500 annual support + 2% of gross revenues jobs. Maybe these are just intended to be added features for their existing SNMP customers.
BTW, EJTools has added a really nice live Swing charting component to their slick JMX Administration console:
for Web applications check out also JSP based management console:
The product costs $3,000.
Could you please give us some examples of what you instrumented and exposed to JMX?
For a reasonably-detailed case study of a financial services application that highlights the compelling value proposition, please see http://www.adventnet.com/article/adtmag1.html
Just that u seem to have a smaller market segment as target customers.
I have posed the same question here in the Discussions and on the JBoss JMX forum, and I haven't received one response. I've searched the web over and haven't found any examples of how a projected used JMX. I've looked over the code on my last project and I don't see much use in instrumenting my objects with JMX.
I don't know if this JMX technology is just too new to have real examples or if it's just not that useful. It's hard to separate the hype from the really useful.
We are using JMX at my current consulting engagement. Client management sees its value in creating 'the real time enterprise' because it is a relatively quick and standard way to monitor the state of applications in production.
I think we are going to hear a lot more about this. Can we roll our own ? Absolutely. Only time will tell if JMX makes it cheaper or more expensive. Based on my own expewreince with standard interface specs ... well, what do you think ? ;-)
Sorry, Mike. You need an example ...
We use JMX to monitor the number of available threads in a WebLogic server's execute queues compared to the number allocated. We email warning to production support people when the ratio gets too small. This gives us an early downtime warning. (It's a long story.)
Anyway we have been able to reduce downtime in these situations from an average of 40 minutes to an average of 10 using the early warning. Not that those numbers mean anything to any other project, but the effort is more than paid for in the 6 weeks we have been using this, and we are only starting to instrument the app environment in this way.
Thanks for your example. When you say the number of threads compared to the number allocated, is this a WebLogic object or your own object? I think JMX is really valuable for managing servers, but when it comes to applications I'm having a hard time seeing opportunities to use JMX.
It is true that Application Server Vendors have found JMX to be the right Java based Management Solution( their support for JMX establishes this). Nevertheless, it is as valuable for Application Management also, else how would you expect to remote manage your applications without any management aspect incorporated to your Application Development. A Management Interface has to be exposed to make it remote managed and JMX exactly does this. Another advantage would be that it encapsulates and leverages existing management practices in use.
Hope this helps
This is getting closer to my point. In my previous projects, I've written user stories for administration things that would be done by the administrative users. I think this makes sense. Where JMX fills in a potential gap is by offering managing for non-typical users (developers and administrators). But I'm having a hard time coming up with examples of what a developer would need to configure at run time. I've looked over my previous projects and I don't really see anything to expose with JMX. I'm hoping someone who's done it can share their experiences with it. So far I get the impression that there aren't many people using JMX.
I recently built a large system for a client which was running in the order of 20-30 worker threads. There was a lot of different things to administer, and we used JMX to take care of it.
1) If a task fails for some reason, it can be suspended or resumed using only it's task ID (which is emailed to the support team the first time it fails.)
2) The support team can view the logs, and "grep" for the offending ID, and see the subsequent x lines of log file, which lets them view stack traces etc. to troubleshoot the problem.
3) The worker threads can be suspended and resumed.
4) Meta-data is cached in memory, and is reloaded periodically via a background thread. This thread can be suspended and resumed, or alternatively, a manual reloading of the meta-data can be triggered.
5) The system can be shut-down or restarted. (The latter one requires some slight of hand. A "restart" merely creates a marker file and then shuts down the JVM. The shell script which started the JVM spots the marker file, deletes it and runs the JVM again. Simple but effective.
The above took me the sum total of about 2 hours to develop. I was using MX4J. I also took their standard XSL files and spent 30 minutes tweaking them to give my client an HTML interface which fits in with their corporate look and feel.
So, I spent less than 3 hours providing management of a lot of different things. It's effective and it works. If the client ever decides to go to a more standard management console, they can simply plug in the relevant adapter (which is just an MBean so it's a class name change in our configuration file) for that console and their up and running.
Hope that's the kind of answer you were looking for. Some of this is similar to managing a server, but a lot of it isn't. It's application domain specific.
Thank you very much for taking the time to write up how you used JMX. I think you have very good cases for using JMX! I hope someone can add some experiences, especially with an appserver. It'd be great to see how people are using JMX with their EJBs.
has a good JMX book available
. Check it out for some practical examples & paradighms.