> model it uses. Anyway, under LOG4J_HOME/contribs/CekiGulcu 
> you will find a 
> possible table model implementation. It uses 
> a  org.apache.log4j.helpers.CyclicBuffer as the underlying 
> data structure.

That sounds like a very good start, is it ok if I incorporate stuff from
that class into the new model?
 
> What if the user is not there? If the user is there, she 
> might have better 
> things to do than to be distracted by chainsaw. 

I was thinking that each window (we've only got one at this point) MUST
always have some form of Policy configured to deal with the situation, and
the user may decide at any time to change the Policy (if they want to).
This way the user is never interuptted, and ChainSaw will handle the
condition, but has the ability to configure a different policy for their
needs.

Initially, at least, I see the model being configured with the one and only
DiscardOldestPolicy, and provide no GUI element to change it.  This way the
next version of ChainSaw is at least ready for the condition, and in
subsequent versions we can decide to open up the Policy API, implement new
Impl's, and plug the choice into the Preferences framework.

> memory capacity. Given that the size of each LoggingEvent 
> varies, one can 
> compute a reasonably reliable table size assuming a Gaussian 
> distribution 
> for the size of LoggingEvent object. 

Statistics!  *gasp* Definately don't put me in charge of that area if you
want it to work correctly... ;)

I couldn't think of anything more than some rule of thumb, that's perhaps
configurable by the user, perhaps allow a High water mark/hard-limit config
item through the ChainSawAppender in log4j's config file.  It's a bit
arbitary, and a stab in the dark, I agree.  (Actually doesn't LF5 have a
defined hard-limit?)

> Alternatively, when 
> chainsaw runs out 
> of memory it could simply discard say 20% of the events, and 
> stick to 80% 
> of the peak size.

I'm not sure of the success rate of catching OutOfMemory (unless there's
some other mechanism?? ).  Probably best to force some form of hard-limit,
and perform some operation  like you suggect (disgard 20%, that could be
another Policy impl in itself).

> One other advantage of a fixed sized table is the speed with 
> which elements 
> can be accessed.

Definately.

Paul Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to