Java 2 Platform, Standard Edition (J2SE) 1.5 Monitoring and Management Part 2

Java Live Transcripts Index

Guests: Blake Connell, Mandy Chung, and Sanjay Radia
Moderator: Edward Ort (MDR-EdO)

This is a moderated forum.

MDR-EdO: Welcome to today's Java Live chat on Java 2 Platform, Standard Edition (J2SE) 1.5 Monitoring and Management. This is a continuation of the chat we did on May 20. Our guests today (as they were for the previous chat) are Blake Connell, Mandy Chung, and Sanjay Radia. Blake is the product marketing manager for J2SE. Mandy is the technical lead for J2SE 1.5's monitoring and managing APIs and implementation, as well as out-of-the-box monitoring and management. Sanjay is the overall RAS architect for J2SE. They're ready to answer your questions. So let's begin. Who has the first question?

JayMX: Are there going to be sessions on J2SE 1.5 monitoring and management features at JavaOne?

Mandy Chung: Yes, there is a J2SE 1.5 Monitoring and Management session (TS-2861) at JavaOne and there is a JMX session (TS-1304).

kto: Are there some small M&M demos available to browse in J2SE?

sanjay radia: There is the jconsole tool, available as part of JDK that will let you browse a JVM and also observe application MBeans.

Mandy Chung: In addition to Sanjay's previous answer, there will be sample code included in the SDK to demo the usage of the java.lang.management API.

mike: Are there J2SE 1.5 management features added explicitly to support Java 2 Platform, Enterprise Edition (J2EE) management efforts?

sanjay radia: The management features are fairly generic for both J2EE applications and other Java applications. Although nothing specific was added that was only for J2EE, we did look into the requirements of J2EE.

antoniov: Hello. Is there any sample code available with JDK1.5 Beta 2? Thanks.

Mandy Chung: The sample code wasn't ready in time for beta2 but will be in the next release.

JayMX: When will this be available? Where can I get more information?

Blake Connell: Beta 2 of J2SE 1.5 is shipping right now, and you can download it here. Sun anticipates the final release to be available at the end of September 2004.

ghinkle: Did you consider making the threadgroup information available as well?

Mandy Chung: We considered it and decided not to, since thread groups are largely obsolete. Reference Josh Bloch's book "Effective Java".

JayMX: I'm concerned about the proper use of JMX, particularly in terms of performance hits. Are there any documented guidelines or recommendations concerning JMX performance? For example, if I want to monitor garbage collection (GC) in the Java virtual machine¹ (JVM), are there any guidelines regarding proper implementation of the Garbage Collector MBean?

sanjay radia: As a user observing a JVM, you do not really need to worry about the implementation of a GC MBean. GC and memory management information is provided via MBeans built into the JRE. In addition, there is not much performance impact of the MBeans themselves. Things that have a performance impact (like amount of time spent blocked on a monitor) are optional. There is some additional overhead if you are monitoring a JVM remotely - network processing of the requests. Again this is very small overhead.

antoniov: Hi again. I cannot cache a jvmtiEnv* between method calls, right? (same as JNIEnv* for JNI).

Mandy Chung: You can send this question to the JVMTI team. There is an alias for JVMTI as well as other J2SE technologies.

JayMX: Aside from the technical sessions, where else can I see you guys at JavaOne?

Blake Connell: The Monitoring and Management team plan to be on the Pavilion floor in the Sun booth. There will be a J2SE 1.5 "Ask-the-Experts" pod. We'll post the times when we'll be there, so swing by our pod and say 'hello.'

Andi: What kind of overhead does enabling the MBeanServer add? What is available with and without the MBeanServer, i.e. just the console?

sanjay radia: By default you can access the MBeans locally within the address space. If you enable the MBean server then you pay a little extra overhead in space. Then if there are remote clients that are accessing information via the MBean server, then the overhead depends on how frequently the monitoring requests come in and the amount of information that is being accessed. However, we took this issue into account when we designed the system, and the overhead is quite low. Also, this is an area where we will continue to improve.

mike: Does the out-of-the-box VM monitoring data include thread scheduling data? For example, threads that are consuming high percentages of VM time? How about capability to do something about such threads without stopping the VM?

Mandy Chung: There is no thread scheduling data provided in 1.5. But there is detailed thread information available such as thread stack trace, thread state, the monitor lock the thread is blocked on, and some thread contention statistics. You can also get thread CPU time. Most thread information does not require stopping the VM. Thread stack trace and on-demand deadlock detection are the ones requiring stopping the VM in 1.5. In the next release, we plan to enhance the implementation to not require stopping the VM for these capabilities.

mike: Sorry I haven't looked at the jconsole tool yet, but does it have the ability to connect to and report multiple VMs simultaneously?

sanjay radia: Yes, you can monitor multiple local and remote JVMs with jconsole.

mike: Have you looked at the consoles of other VMs? For example, BEA's JRockit has a decent gui console. Are you looking to provide that level of interface in the future?

sanjay radia: Our jconsole (see beta2) has a nice simple gui to display a variety of information about the JVM (memory, threads, classes, cpu usage, etc.).

Andi: How is the remote (JSR-160) connector started?

sanjay radia: See the Out-of-the-Box page - it explains how to start the 160 connectors.

Andi: Would these configurations (e.g., enabling the monitoring of time spent blocked on a monitor) be done from the console (or programmatically with a calls on MBeans), or what ways are there? Is such configuration transient, i.e., will be re-set after JVM re-start?

Mandy Chung: The thread contention monitoring enablement can be configured from the jconsole through the MBean tab. You could certainly do it programmatically (see the java.lang.management.ThreadMXBean API). The setting is only for one particular VM. For persistent configuration, you could use a management properties config file to store your pre-defined setting.

fkieviet: Are there any plans to backport the JDK 1.5 JMX extensions to JDK 1.4?

sanjay radia: JMX 1.2 and JSR-160 (RMI connectors) that are a part of JDK 1.5 are available separately for JDK 1.4. However the instrumentation of the JVM that is in JDK 1.5 is not available for JDK 1.4.

JayMX: Are any of the mainstream vendors implementing these enhancements (e.g., JMX)?

Blake Connell: As a standard derived from the JCP, Sun certainly would like to see the large enterprise management vendors pickup JMX. SNMP-based systems can certainly include JMX.

sk: Can we get data about GC from the VM's viewpoint using JMX hooks?

Mandy Chung: There are some GC statistics available in 1.5 (see the java.lang.management.GarbageCollectorMXBean API). The GC algorithms used by different VMs vary widely. A GC implementation typically has various GC-specific monitoring information. The API design allows each VM vendor to provide their GC-specific data as platform extension as part of the MBean management interface. The standard GC statistics as well as the platform extension can both be accessed via JMX in an MBean. Sun's implementation includes some GC-specific management support, such as the platform extension.

antoniov: I'm taking a look at jstat and it seems to me it's quite a powerful tool for GC tuning. Now I'd like to have *all* information (-gccapacity, -gcutil) in a single command line option. Will you, please, add that for JDK 1.5 final?

sanjay radia: I guess you are looking for an -all option to jstat. That is a good suggestion but I don't think we can get it in for the final release at this late stage. We will consider it for future releases. For now you will have to list all the options explicitly. For those who haven't used jstat yet, it is a utility to display information about various aspects of the JVM using a command line. You can easily redirect the output to a file for later processing and review.

antoniov: You mean I can add several options in the a single call (I mean -gccapacity and -gcutil) at the same time? That's great! (you should update the docs, then ;-) )

sanjay radia: Yes, you can.

Andi: Does the JVM instrumentation include JMX notifications?

sanjay radia: Some of our instrumentation uses JMX notification (memory usage notification). Is that what you meant by your question?

Andi: Yes.

Blake Connell: I've got to run but thanks for participating today. We hope to see you at JavaOne at the end of the month - it's a great opportunity to meet the developers and really dive into Monitoring & Management.

MDR-EdO: Thanks Blake. Mandy and Sanjay are still here to answer questions.

JayMX: What kind of information can I get about my threads? Can I get a thread dump?

sanjay radia: The java.lang.management API allows you to get the thread state, the object that a thread is blocked on and its owner thread, the stack trace, and some thread contention statistics.

Guest: I noticed the proxies from newPlatformMBeanProxy don't seem to handle calls that return CompositeData objects. Is this by design, user error or something else?

Mandy Chung: One of the major API design issues we considered is interoperation which is very subtle but very important. JMX is very flexible, allowing an MBean to use any arbitrary Java types in the return type and in the input parameters. To have a management interface (MBean) using arbitrary data types, a client monitoring a VM must have the classes used by the MBean. It would also require the implementation classes that support it. The MXBean design is around interoperation, so that the MXBean can use certain complex data types (such as MemoryUsage, ThreadInfo) and it doesn't require the client to have those classes available (e.g., a client can run on JDK 1.4 solely using the MBeanServer API). The data sent on-the-wire format is only in basic types and JMX data types. The newPlatformMXBeanProxy method is designed to construct a MXBean proxy to handle the on-the-wire format.

JayMX: Can I figure out if my application is about to run out memory?

sanjay radia: The API allows you to set a threshold for monitoring the memory usage or after GC usage. The VM will send you notification when the usage exceeds the threshold. If you observe that the memory usage keeps increasing even after garbage collection for some time, it's a symptom indicating that it may run out of memory if the usage pattern doesn't change.

SergeBo: Which features of JVMTI are not supported?

sanjay radia: Our focus for this livechat is jmx and management. What were you concerned about wrt to JVMTI?

DaveM: Can you also get an SNMP Trap?

Mandy Chung: Yes, you can get an SNMP trap for the low memory notification. You need to configure where the trap is sent to. The out-of-the-box management documentation talks about that.

MDR-EdO: Well we've quickly come to the end of our session. I'd like to thank everyone who participated today. I thought we had a very nice set of questions. And of course I'd like to thank our guests Blake, Mandy, and Sanjay for their answers.

sanjay radia: You can get more information on Monitoring and Management here. Also at the 2004 JavaOne Conference (in couple of weeks) there are two related talks: one on JMX and the other on management. Also there are labs on out-of-the-box management and jmx (lab # 7322).

Mandy Chung: It was fun. Thanks for being here in the chat and all the questions. Hope to see you at JavaOne.

sanjay radia: It was fun. Thanks for the questions. See you at JavaOne. Bye.