incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Snapshot Application development usecases
Date Mon, 04 Jan 2010 17:44:51 GMT
Happy New Year everyone!

The usecases are interesting, the problem is how to find and dump what 
you want and no more.

Ways in which objects may be selected for dumping:

     o By classloader
         This is can separate object instances at runtime by virtue of 
their classes having been
         defined by the same classloader.

     o By class package
         Simply filter dumped classes matching a given filter name.

     o By class annotation
         Classes could be specially marked with an annotation that is 
visible at runtime.

     o By object instance.
        A dump would have to be initiated /somewhere/. Realistically, 
we'd have to start from a particular
         object, class. An array could be passed to cater for multiple 

     o By Thread.
         Using a thread and all of its roots would be practicable if 
they were accessible.

     o By field value:
         Restrict dump to objects with a field containing a certain 
value, determined at runtime.

     o By distance from the root object.
         For example, given an object, only retrieve objects three 
references away.

These could be used in various combinations. Dumping all objects of 
classes in package com.silly.donkey
is all very well, but this could be restricted to only those annotated 
with @DumpMe and further restricted
to only those reachable from a particular instance of 
"com.silly.donkey.HeeHaw" .


Steve Poole wrote:
> I want to present a few application development usecases for us to discuss
> to do with the Snapshot concept.
> First let's agree some basics
> An application snapshot is a deliberate subset of a running system.  It's
> deliberate in that what is defined for inclusion / exclusion can be changed.
> To build an application snapshot three types of information are required
> 1 - root objects which determine where to start the snapshot from
> 2 - rules to restrict how "far" to search
> 3 - rules to describe what to include in the snapshot
> Example 1
> A webserver session is behaving incorrectly.  The application programmer
> wants to capture information
> to do with the session itself and some specific application details.
> The root object is an HTTPSession and the application code is all contained
> in packages that start org.acme.application
> The application programmer believes that the problem is in the application
> and so wants the minimum
> of system information included.
> Example 2
> An error has occured and the application is about throw an exception.  The
> application programmer wants to capture a series
> of objects related to the error and wants to see the Java stack including
> local variables.
> Example 3
> A enterprise server is running slow and the application programmer would
> like to get a list of the instances of a specific interface
> that the server is managing, since the suspicion is that there are multiple
> instances of a nonthreadsafe instance of this interface when there should
> only be one.
> Example 4
> A servlet server has run out of database connections and the suspicion is
> that managed objects have not been
> collected.  Typically programmers use finalisers or depend on GC instead of
> using the Servlet.Destroy() method.
> the application programmer needs to get a list of objects in "Destroyed"
> state which obviously haven't been GC'd
> Cheers

Stuart Monteith

View raw message