incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sonal Goyal <sonalgoy...@gmail.com>
Subject Re: Snapshot Application development usecases
Date Tue, 05 Jan 2010 15:34:04 GMT
Hi,

A very happy new year to everyone. For the cases mentioned, we can slightly
modify Stuart's approach and allow user defined filters:

interface DumpFilter<T> {
     boolean includeInDump(T t);
}

class ClassLoaderFilter<ClassLoader> implements DumpFilter...
class ThreadFilter<Thread> implements DumpFilter<Thread> {
   private ArrayList<Thread> threads;
   public ThreadFilter(ArrayList<Thread> threads) {
        this.threads = threads;
   }

  boolean includeInDump(Thread t) {
       if (threads.contains(t)) return true;
       return false;
  }
}


class Dump{

    void dump();
    void dump(Object..roots);
    void setDepth(int depth);
    void addFilter(DumpFilter df);
    Set getFilters();
    void setFilters(Set filters);
}
Thanks and Regards,
Sonal


On Tue, Jan 5, 2010 at 7:21 PM, Stuart Monteith <stukato@stoo.me.uk> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message