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