Using JDB for Fault recovery

> 1. Is it best to use the JDI for application

> monitoring. Else, which is the best option. I think

> JVMPI would be very heavy.

JVMPI was an experimental interface that will not be around

in the long term. The replacement interface for Profiling,

Debugging, and Monitoring & Management is called JVMTI

(JVM Tool Interface). The design and development work was

done under JSRs 163 (Profiling Architecture) and 174 (Monitoring

and Management). For more information, take a look at :

http://www.jcp.org/en/jsr/detail?id=174

http://www.jcp.org/en/jsr/detail?id=163

For an overview of JDI, you may want to study the diagram

in this Architecture Overview document:

http://java.sun.com/j2se/1.4.2/docs/guide/jpda/architecture.html

> 2. The MFT will be enabled by default. Hence, it is

> important that it does not affect ny application's

> performance much.

You will have to test your application and measure whether

the impact will be acceptable. It should be. Take a look at

this white paper:

http://java.sun.com/products/hotspot/docs/whitepaper/Java_HSpot_WP_v1.4_802_3.html

> 3. The MFT must have options to enable and disable it

> completly at run time.

The current Java Debugger Interface (JDI) is enabled or disabled

at VM start up time. Refer to "Connection and Invocation Details"

http://java.sun.com/j2se/1.4.2/docs/guide/jpda/conninv.html

This restriction will be removed in the future, via JSR 163.

> 4. If JDB satisfies the above mentioned criteria

JDB is a simple command-line debugging tool that demonstrates

use of the JDI (Java Debug Interface) API. It would be a good idea

for you to study all of the examples listed on the "Example JDI Applications"

page:

http://java.sun.com/products/jpda/examples.html

The demo code is available in your SDK installation, under

$JAVA_HOME/demo/jpda. Just unpack examples.jar to look

at the demos, compile them, and run them.

>Is it possible to start the JDB in the same JVM as that

> of my server instead of launching my server from JDB.

This is not recommended because it will usually lead

to deadlocks and hangs. Refer to this question in the FAQ:

"Why do debugger applications run in a separate VM from the debuggee?"

http://java.sun.com/products/jpda/faq.html#IA3

If you run your monitoring agent in a separate, standalone VM, other

advantages would be:

1) It could run on a separate machine

2) It could be designed to monitor multiple VMs running your application(s).

3) A fatal bug in the agent will be less likely to take down your application

debugging_teama at 2007-7-16 0:22:47 >

I only have answers for 1.5. With JVMTI, you can Tag a jclass object, then traverse the Heap and find all objects that are instances of that class. Pre 1.5, you would need to look at JVMPI, which is a dead end feature, or look at JVMDI and RedefineClasses().

Monitoring by way of method entry will be expensive unless you do something like BCI on the class of interest. You would inject a call to some static method into the bytecodes of the method of interest, then you can do whatever you want in that static method to track time etc.

You should also look into:

http://java.sun.com/j2se/1.5.0/docs/guide/management/index.html

kellyohaira at 2007-7-16 0:22:47 >