incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Snapshot Application development usecases
Date Tue, 05 Jan 2010 13:51:17 GMT
Given a method:
     dump()

to generate a dump, this could be expanded with:

     dump(Object obj)

which would dump that object and what it refers too.

Of course, doing the following:

Object[] obj;

     dump(obj)

I would expect that a Dump object would be created and used in multiple 
places, configured for use by whatever.
The object passed to the dump method would be used as the context in 
which the dump was to be taken.

Commonly, we might expect:

     Object[] context = new Object[2];
     context[0] = Thread.getCurrentThread();
     context[1]= HTTPSession;

     dumpObj.dump(context);

which the dumpObj has already been configured for.

class Dump {
     // Generate a dump.
     void dump();

     // Generate a dump, including the passed root object.
     void dump(Object root);


     // Get the roots already
     Set getRoots();

     // Sets the number of references
     void setDepth(int depth);

     // Sets the objects to start scanning from
     void setRoots(Set col) ;

     // Get the set of classloaders dumps are filtered against.
     Set<ClassLoader> getClassLoadersFilter();

     // Set the classloaders to filter against.
     void setClassLoadersFilter(Set<ClassLoader> loaders);

     // Set the packages to filter against
     Set<String> getPackagesFilter();
     void setPackagesFilter(Set<String> packages);

     // Filter by sets of Threads.
     void setThreadsFilter(Set<Thread> thread);
     Set<Thread> getThreadsFilter();

     ... etc..
}


Of course, filtering on annotations, classloader and packages are 
essentially filtering by operations on classes.
Presuming the filtering is performed in Java, we could simply provide an 
interface to determine this:
     interface ClassFilter {
         // Return true if class is to be included.
         boolean filter(Class clazz);
     }

We could provide implementations of ClassFilters to perform the operations.

I am a little concerned about how to implement this stuff. If it is 
Java, we need a virtual machine,
and the one we are in may be failing in such a way we can't execute - an 
OutOfMemoryError or
StackOverFlowError are both obvious examples.

Regards,
     Stuart



Steve Poole wrote:
> 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/
>>
>>
>>      
>
>    

-- 
Stuart Monteith
http://blog.stoo.me.uk/


Mime
View raw message