incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Runtime Investigator usecases
Date Tue, 24 Mar 2009 09:35:10 GMT
Hi All -  I've been thinking about the usecases we could image for
investigating the contents of diagnostic artifact.   I initially described
the tool as

"A program that can examine a dump and provide guidance on common aliments.
This tool will provide analysis modules that can report on such items as
deadlock analysis,  heap occupancy etc The tool will provide extension
points that will allow others to contribute new analysis modules.  Key
characteristics of this tool will include handling large quantities of data
efficiently  (probably via a query language of some type) , ensuring the API
is generally consumable by programmers and ensuring the API provides the
data that is actually required to analyze real problems."


This tool is probably one of the most important and all encompassing we
have. so the user story list for this tool could be quite large.  Rather
than attempt to list everything I'm going to list some examples and see what
you all think.


RI1: As a programmer diagnosing an application failure,  I want to see  the
threads that were active when the dump was created including the java stack
and native stack so I can see where my application was when it terminated

RI2: As a programmer diagnosing an application failure,  I want to see  any
native library code and what entry points in the library are active on the
thread stacks so I can see where my application was when it terminated

RI3: As a programmer diagnosing an application hang or deadlock, I want to
see  what monitors are held and or waited for by the various threads so I
can see what my application  was doing at the time.

RI4: As a programmer diagnosing an application hang or deadlock I want to a
report of any deadlock situations including a list of threads, monitors and
associated java code involved, so I can see what my application  was doing
at the time.

RI5: As a programmer diagnosing an application hang I want to see what
threads are waiting for a response from an external process,so I can see
what my application  was doing at the time.

RI6: As a programmer diagnosing an application failure, I want a report of
jvm launch information including command line , environmental variables etc
, so that I can check that my starting assumptions are correct

RI7: As a support engineer receiving the diagnostic artifact I want to know
what was the  the initiating cause of the dump - ie out of memory, process
failure,  snapshot triggered

RI8:  As a programmer diagnosing an out of memory situation , I want a
summary report of the heap which  lists number of objects generally and
specifically - ie bytebuffers . classloaders. so that I can understand the
characteristics of the problem

RI9:  As a programmer diagnosing an out of memory situation , I want a
summary report of root objects that retain large amounts of heap, so that I
can identify potential culprits.

RI0:  As a programmer diagnosing an out of resource situation ,I want a
report of open sockets and paths to them from thread roots


Steve

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