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: [EMAIL PROTECTED]
--
Ceki
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
