incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Snapshot Application development usecases
Date Mon, 04 Jan 2010 22:23:26 GMT
Thanks Stuart - like the donkey.

I would imagine,  based on your examples,  having methods like

selectClassesLoadedBy(ClassLoader c)
selectPackageName("com.silly.donkey.*")
selectByAnnotation(Annotation a)
selectReferencedObjects(Thread t);
addFieldFilter(java.lang.reflect.Field f,Object value);
selectReferencedObjectsWithin(Object root,int distance);


I like to get down the the method definitions as quickly as possible as it
makes it real :-)


On Mon, Jan 4, 2010 at 5:44 PM, Stuart Monteith <stukato@stoo.me.uk> wrote:

> 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 roots.
>
>    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" .
>
>
> Regards,
>    Stuart
>
>
> 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
> http://blog.stoo.me.uk/
>
>


-- 
Steve

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