log4j appender : buffered holder: only write to file on error

Question

I'm looking into the idea of creating a new logger to hold log statements internally until an error occurs.

So in the system I'm working on, it is a sequence process (no parallel work, with a set start point and end point). I'd like to have my info() lines buffered in memory & at the end if an error occurs, flush them out, or if its a success then don't bother logging them.

I'm not too worried about memory use, its only 15 lines at a time (across several classes). But since it can process 100's of items a second(each creating 15 lines), the logging can become verbose with data that isn't that needed.

The other option it to log to one main file, which can be tailed. Then if an error occurs, flush the last buffer to an ERROR log.

Does anyone know of a SLF4J-LogWriter or LOG4J-Appender that does this already before I go creating my own?

I can see http://sling.apache.org (org.apache.sling.scripting.core.impl.LogWriter) already does something similar, but will probably required me to hack the code out.

Thanks Jeff Porter

Answer 1

I did the same for log4j and logback; AFAIK, there is no ready-made solution.

For additional usefulness, my implementation buffers log messages on all levels and you can configure the number of messages to keep per level.

When an ERROR is logged, I dump all messages in order.

Some comments:

• Create one buffer per level. That makes it very simple to keep N messages per level (where N depends on the level; you usually want more DEBUG messages than INFO messages).
• You will need an AtomicInteger or AtomicLong to give each message a unique ID. You will need that later to sort them into an order from the different buffers.
• You will need to run the root logger with DEBUG threshold because no appender will ever see messages below the root loggers level.
• You will have to configure a threshold filter into all other appenders.
• Since most of the operations are in-memory (almost no log messages will be written to disk), this is actually not as bad as it sounds.
• This is much more simple to implement in logback than log4j.