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 Thu, 07 Jan 2010 14:17:24 GMT
Thanks Sonal.
I've been mulling over this idea and  I agree that it would be a good way to
go.  However I do worry about giving the application programmer this
capability. My worry is that if the dump generator  mechanism was run
"outside" the JVM then it would not be able to run the user code.  I really
would like to see if we could come up with a declarative form of an API
where we could do the equivalent in some  non executable form.  Of course it
may end up not being practical but I do want to make sure we have given due
consideration to  the concept.

I


On Tue, Jan 5, 2010 at 3:34 PM, Sonal Goyal <sonalgoyal4@gmail.com> wrote:

> 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/
> >
> >
>



-- 
Steve

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