incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Update - almost a milestone
Date Tue, 23 Jun 2009 21:00:32 GMT
Today we finished getting the codebase building on the Apache hudson
server.  You can see the status of all the bits here
http://incubator.apache.org/kato/site/buildstatus.html

This means that there is now code you can download and use.   Most of it is
not yet  in a simple form to use -  but we've packaged up the katoview tool
so that all the required code is in a single jar.  Its got a long name but
you can download it and give it a spin.  Right at this moment it can only
handle hprof files.

The link is
http://hudson.zones.apache.org/hudson/view/Kato/job/org.apache.kato/lastStableBuild/org.apache.kato$kato.tools.katoview/artifact/org.apache.kato/kato.tools.katoview/0.0.1-SNAPSHOT/kato.tools.katoview-0.0.1-SNAPSHOT-jar-with-dependencies.jar

Assuming you rename the jar to   katoview.jar then to use the tool with an
hprof dump you do (note that the hprof file must end with .hprof)

 java -jar katoview.jar -core hproffile.hprof

You'll get a prompt and you can type help for further info.

Not everything is going to work since a hprof file has no process
information in it but assuming you have a reasonable hprof binary file to
hand you should be able extract information of some sort.

The tool has a couple of additions from the version that was contributed by
IBM.   We've added support to extract information about tomcat if the dump
comes from a running server.  We've also added simple support for using
xpath.  That means you can issue the command   "xpath runtime threads/name"
and get a list of thread names.   We've embedded jxpath to do the hard
work.  It  uses beaninfo type patterns to navigate the API    If you look at
the API (
http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-head/javadoc/)
 you'll see that from the JavaRuntime class you can call getThreads()
and
from the JavaThread you can do getName()      jxpath joins these together
and lets you issue xpath commands to navigate the API relationships.


 Xpath is a reasonable query language and I want to explore if it works for
us.    Here are some examples we've come up with that you can type into
katoview


Names of all JavaThreads:
    xpath runtime threads/name

Stacktraces of a named java thread
    xpath runtime threads[name='TP-Monitor']/stackFrames/location

All defined classes
    xpath runtime javaClassLoaders/definedClasses/name

All of the fields defined for a named class:
    xpath runtime
javaClassLoaders/definedClasses[name='java/lang/String']/declaredFields

A field declared in a class by name:
    xpath runtime
javaClassLoaders/definedClasses[name='java/lang/String']/declaredFields[name='value']

All fields with the name "value"
    xpath runtime
javaClassLoaders/definedClasses/declaredFields[name='value']

All objects class names:
    xpath runtime heaps/objects/javaClass/name

Finding immediate subclasses of a given class by name:
    xpath runtime
javaClassLoaders/definedClasses[superclass/name='org/apache/jasper/runtime/HttpJspBase']/name

Find all instances of java/lang/String on the heap: - Really slow!
    xpath runtime heaps/objects[javaClass/name='java/lang/String']

Retrieve the type of a specific object with a given address: - really slow!
    xpath runtime heaps/objects[ID/address=8585216]/javaClass/name


Please have a play and give your feedback -  not only on the xpath support
but on anything else.


Cheers

Steve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message