Hello,
As Steve said, some changes have been made to KatoView, to help demonstrate the use of the API.

We've added some support for dumps from Tomcat and for queries to be generated using xpath queries.

The Tomcat commands were written to show you can extract application specific information using Kato. The commands get easy, obvious things. I would like for the commands to present information that would
help diagnose real problems.

tomcat version
========== This returns the version of the tomcat server that was present in the dump, if any.

For example:

> tomcat version
Found Tomcat server:
   Info: Apache Tomcat/5.5.27
   Built: Aug 28 2008 10:08:26
   Number: 5.5.27.0

It is implemented by finding a class of a name, and retrieving its statics.

tomcat pools
=========

This shows the shallow status of the threads pools, to give some idea how busy the tomcat server is.

For example:
> tomcat pools
Found thread pools
Pool name:http-8080, threads: 25, busy: 2
Pool name:TP, threads: 4, busy: 1

This just finds instances of objects of a particular class and prints out it's instance fields. This notionally shows how busy
the server is.

tomcat jsp
=======
This command is a bit more sophisticated. It is supposed to find the installed and running JSPs in a tomcat server. It first of all finds all classes that subclass HttpJspBase, reports them, and finds all instances of them. It then looks through all threads for threads with stackframes with methods that are in each JSP's class to show
what each JSP is doing at the time the dump was taken.
With the deadlock.jsp demo, it is possible with the "deadlock" command and this to show the JSPs causing the deadlock, and
where.

> tomcat jsp
Found JSP:  org/apache/jsp/dump_jsp, instances:
   0xe68f10

JavaThread:
   Java stack trace for thread `http-8080-Processor24'
   =========================================================

   com.ibm.jvm.Dump.SystemDump()
   org.apache.jsp.dump_jsp._jspService(dump_jsp.java:108)
   org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331)
   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) : : : : : : : org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
   java.lang.Thread.run(Thread.java:810)



xpath
====

This command uses JXPath to traverse the object structure.
The queries I've put together so far are:

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

The "runtime" option starts the query at the JavaRuntime level, otherwise it starts at Image.

For example, to get all of the thread name:

> xpath runtime threads/name
1:    "main"
2:    "JIT Compilation Thread"
3:    "Signal Dispatcher"
4:    "Finalizer thread"
5:    "ContainerBackgroundProcessor[StandardEngine[Catalina]]"
6:    "http-8080-Processor1"
7:    "http-8080-Processor2"
8:    "http-8080-Processor3"
9:    "http-8080-Processor4"
10:    "http-8080-Processor5"
11:    "http-8080-Processor6"
12:    "http-8080-Processor7"
13:    "http-8080-Processor8"
14:    "http-8080-Processor9"
15:    "http-8080-Processor10"
16:    "http-8080-Processor11"
17:    "http-8080-Processor12"
18:    "http-8080-Processor13"
19:    "http-8080-Processor14"
20:    "http-8080-Processor15"
21:    "http-8080-Processor16"
22:    "http-8080-Processor17"
23:    "http-8080-Processor18"
24:    "http-8080-Processor19"
25:    "http-8080-Processor20"
26:    "http-8080-Processor21"
27:    "http-8080-Processor22"
28:    "http-8080-Processor23"
29:    "http-8080-Processor24"
30:    "http-8080-Processor25"
31:    "http-8080-Monitor"
32:    "TP-Processor1"
33:    "TP-Processor2"
34:    "TP-Processor3"
35:    "TP-Processor4"
36:    "TP-Monitor"


You can see how the results correspond with the "tomcat pools" command.
The numbers on the left are indexes. Using them, the xpath query could regenerate the stacktrace the "tomcat jsp" command's backtrace:

> xpath runtime threads[29]/stackFrames/location
1:    com.ibm.jvm.Dump.SystemDump()
2:    org.apache.jsp.dump_jsp._jspService(dump_jsp.java:108)
3:    org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
4:    javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
5: org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:331) 6: org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
7:    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
8:    javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
9: org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) 10: org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) 11: org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) 12: org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
   <truncated>

This is equivalent to:
   xpath runtime threads[name='http-8080-Processor24']/stackFrames/location

Unfortunately, finding heap objects appears to be very slow, but it at least shows the potential.


Regards,
   Stuart

Reply via email to