logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [ChainSaw] internal TableModel size & memory considerations
Date Tue, 25 Feb 2003 06:40:34 GMT
At 02:09 PM 2/25/2003 +1100, Paul Smith wrote:
>I think I read somewhere that LogFactor5 can place a bounds on the # of
>events that can be held in the internal structures to prevent Memory hogging
>(I may be wrong).  I can't see that ChainSaw has this feature.

This is the feature that I tend to care about most, because in any 
real-world system, the number of generated events over time is bound to be 
large. If each of these events is kept in memory, then chainsaw will 
eventually run out of memory. It is not a question of if but when. Thus, 
the ability to replace the table model seems very desirable. I no longer 
remember whether the rest of chainsaw code makes assumptions about the 
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.

>There's a couple of ideas here:
>
>* Allow the definition of a limit via configuration, and have a coloured bar
>somewhere in the panel indicating when the # of entries in the internal
>structure passes through some thresholds (maybe green->yellow->orange->red)
>
>and/or
>
>* Allow the user to choose a Policy which determines what to do when a limit
>is reached.  We could have a DisgardOldestPolicy (rolling window),
>DisgardNewestPolicy, DisgardDebugPolicy

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. In principle, the user 
should not need to intervene while chainsaw is running. Nevertheless, your 
suggestions are ivery nteresting. They lead to the following refinement (or 
simplification depending on the point of view). When chainsaw detects that 
it just ran out of memory, it will discard a number of events and stick to 
a fixed size table where the size is the largest possible given the current 
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. Alternatively, when chainsaw runs out 
of memory it could simply discard say 20% of the events, and stick to 80% 
of the peak size.

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

These are just some ideas.



>cheers,
>_________________________
>Paul Smith
>Lawlex Compliance Solutions
>phone: +61 3 9278 1511
>email: paul.smith@lawlex.com.au

--
Ceki 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Mime
View raw message