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: [TOPIC] Snapshot data collection definition - dump triggers
Date Fri, 20 Nov 2009 10:50:50 GMT
On Thu, Nov 19, 2009 at 11:37 AM, Sonal Goyal <sonalgoyal4@gmail.com> wrote:

> Hi Steve,
>
> Do we see a scenario where different timers will be capturing different
> data
> ? For example, simple dump of class instances every nth interval, and
> detailed dump every mth interval?
>
> Hmm - yes I suspect you're right - that does sound likely.


> For event driven dumps, we may like to look at JNI related crashes.
>
> Agree -  we do we want to do that.    I don't know if there is any way of
specifically noticing a JNI crash though.
  It would be great to do something like Dump.setOnJNICrash(true)   but I
don't know if we can actually seperate out
the event from just a straightforward dump request.

Thanks and Regards,
> Sonal
>
>
> On Tue, Nov 17, 2009 at 4:16 PM, Steve Poole <spoole167@googlemail.com
> >wrote:
>
> > Andreas posted some interesting information here
> >
> http://mail-archives.apache.org/mod_mbox/incubator-kato-spec/200911.mbox/%3C6EB74B946FF4CF4BAA39332269A659D50data
> > in the24AE296@DYNASERV.dynatrace.local%3E<
> http://mail-archives.apache.org/mod_mbox/incubator-kato-spec/200911.mbox/%3C6EB74B946FF4CF4BAA39332269A659D5024AE296@DYNASERV.dynatrace.local%3E
> >
> >
> > This thread is to discuss the topic of  how and when  snapshot dumps are
> > triggered.
> >
> > Andreas has started with asking for
> >
> > 1)  scheduled (timed) dumps
> > 2)  event driven dumps including fatal JVM crashed type events
> >
> > Question:    How adaptive would this timed dump have to be?  I can
> imagine
> > having a regular heart beat dump but would we want to be able to modify
> the
> > timeing on the fly?
> >
> > Question:    Would we want to have multiple timers running with different
> > dump output?
> >
> > Question:    What are the top events that we need to consider should be
> > covered -  there is the usual OOM but what else?
> >
> > --
> > Steve
> >
>



-- 
Steve

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