| By Sam Pullara | Article Rating: |
|
| September 23, 2002 12:00 AM EDT | Reads: |
10,129 |
The Java Management API (JMX) has been integral to managing the WebLogic Server since WebLogic 6.0. Through this API you can search for management beans (mbeans) within the application server and query them for both configuration information and runtime monitoring information. In addition, this API can be used to actually change the configuration of the server. In fact, this API is used internally by the console and other administration tools to do their work and report their data.
This API can be a powerful tool for monitoring. Let's look at an example. In this application, you have mostly static content, some JSP pages for your personalized pages, a registration system, a JMS-based data feed, and maybe a small billing application. Where in this application can we use JMX to our advantage? On the static page side, you can access the information for the FileServlet and see how much time was spent serving the static content. It might be less than you expect because of the amount of caching that browsers do automatically on the client side. Most requests for static content will be HEAD requests, checking for changes. For dynamic pages, each servlet in the system is accounted for separately. This data doesn't perfectly reflect the user experience (because the user has the lag between when their request is sent and when they receive the page back), but it does tell just how long each servlet, on average, spends in a request and how many have been made. Our registration system is an entity bean, while the billing system is a stateless session bean backed by an external service. Both beans can be monitored and the information used to tune the size of the caches and pools. Our data feed can also be interrogated to determine if we have been getting as many messages as we have been paying for, or to determine how many subscribers are using the data. Throughput can also be calculated using the attributes on the JMS topic and queue mbeans. Finally, all JDBC connections can be monitored and from their mbeans you can find out how much the pool connections are contended, which will tell you if you need more database client licenses, for instance.
The second use of mbeans in the WebLogic Server is for configuration information. The configuration of all resources is contained at runtime by the configuration mbeans. These mbeans are essentially an instantiated representation of the information contained within the config.xml file. Everything from which applications are deployed to which port a server listens on is contained within these interfaces. Most of the individual attributes are relatively straightforward; however, the collection of attributes that describes a deployment unit is complicated and they have been collected for convenience behind the weblogic.Deployer class. Accessing them directly is possible but not reccommended except for looking at configuration and not changing it. The rest of the attributes are fair game, although beware, most of those attributes will only actually change runtime behavior if the component (like a JDBC pool) is redeployed or if the server is restarted. Applications of these configuration mbeans range from determining the resources that a particular application is using to tweaking values based on the feedback from the monitoring mbeans.
As you can see, there's a lot of information - but how do you get to it if you're new to JMS and the WebLogic Server? It's actually not that hard. As long as you can use JNDI and read JavaDocs you'll find it pretty easy to navigate the hierarchy of mbeans. In the code sample below you can see how you find the local server mbean home and then find the JDBC pool.
MBeanHome home = (MBeanHome) new
InitialContext().lookup(MBeanHome.LOCAL_JNDI_NAME);
Set pools = home.getMBeansByType("JDBCConnectionPool");
This gives you the configuration mbeans for the JDBC pools. If you want to monitor the pools rather than look at their configuration, simply change the type of mbean by adding "Runtime" to it. From this mbean you can determine important information like whether you are leaking connections - you can even get a stack trace of where exactly the connection was allocated!
What if you want to use the JMX mbean system without doing any Java programming, like from a script file? Fortunately, we include a tool that will let you view and change mbeans directly from the command line - weblogic.Admin. In addition to PINGing servers, getting JNDI listings, resetting pools, and shutting down the server, it gives you direct access to the mbean hierarchy. In the next code sample you'll see the equivalent weblogic.Admin command.
java weblogic.Admin -username system -password [password] -url [url] GET
-pretty -type JDBCConnectionPool
This gives you an easily readable description of the mbeans that match the type descriptor plus the properties on those mbeans. Similarly, there is a SET command that will change the properties on any mbean in the system.
Armed with this tool you should be able to monitor your applications internally in Java and externally from scripts.
Published September 23, 2002 Reads 10,129
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Sam Pullara
Sam Pullara has been a software engineer at WebLogic since 1996 and has contributed to the architecture, design, and implementation of many aspects of the application server.
e-mail: sam@sampullara.com
![]() |
Alexander 07/03/03 08:18:00 AM EDT | |||
I would like to recive more jmx examples code, thank You |
||||
![]() |
Chris Dahl 10/16/02 10:16:00 AM EDT | |||
It would be nice to have a few more JMX example code snippits to do some common things like maybe to untarget an MDB that is encountering too many errors. It seems there are very few JMX code examples out there and I find it difficult to glean specific runtime bean behavior control from the manual. |
||||
- Oracle To Keynote Cloud Computing Expo
- The Economics of Cloud Computing Analyzed
- The Difference Between Web Hosting and Cloud Computing
- GovIT Expo Highlights Cloud Computing
- Cloud Computing Best Practices
- Gang of Four Creates Cloud BI Stack
- Tactical Cloud Computing Panel at 1st Annual GovIT Expo
- Citrix Aims To Cripple VMware’s Cloud Designs
- Product Evaluation: JBoss TCO Calculator
- Platform as a Service Journal Launched on Ulitzer
- An Introduction to Abbot
- Oracle To Keynote Cloud Computing Expo
- Will Ulitzer Dominate News Content on The Web? -Gartner
- REA Is Where RIA Becomes the Norm
- The Economics of Cloud Computing Analyzed
- Software AG Named "Gold Sponsor" of SOA World Conference & Expo 2009 East
- The Difference Between Web Hosting and Cloud Computing
- GovIT Expo Highlights Cloud Computing
- Cloud Computing Best Practices
- Gang of Four Creates Cloud BI Stack
- Java vs C++ "Shootout" Revisited
- Where Are RIA Technologies Headed in 2008?
- Configuring Eclipse for Remote Debugging a WebLogic Java Application
- Migrating a JBoss EJB Application to WebLogic
- XA Transactions
- An Introduction to Abbot
- WebLogic Tutorial: "Integrating Apache Poi in WebLogic Server"
- Eclipse "Pollinate" Project to Integrate with Apache Beehive
- Failover and Recovery of Enterprise Applications - Part 1
- Cover Story: A Practical Solution to Internationalization of a J2EE Web App





































