Log4J Appenders

[ TimeAndSizeRollingAppender | ActiveAsynchronousAppender]

Two appenders are provided for use with Log4J 1.2.x. Each is packaged as a separate component in its own JAR, with its own test report, and test coverage report.


This appender can be used as a drop-in replacement for either the out-of-the-box Log4J DailyRollingFileAppender or the RollingFileAppender , and provides features of both. The TimeAndSizeRollingAppender also provides some other useful features not available in either the RollingFileAppender or the DailyRollingFileAppender :



See the TimeAndSizeRollingAppender Javadoc for more detailed information, including sample configurations.


Download the TimeAndSizeRollingAppender

Comparison Matrix

Compare the features of the TimeAndSizeRollingAppender, out-of-the-box Log4J Appenders, and the Log4J Extras RollingFileAppender.

Feature Details

Log file rollover by time or date

Rolls over in a configurable way just as the DailyRollingFileAppender does.

By specifying a date pattern, you specify the maximum period of time during which a log file may exist before it is rolled over to a backup file. Say an appender is configured for daily rolling: a log file created at 5 minutes to midnight will only exist for 5 minutes because the appender will roll the log file into a backup before it starts logging into a new log file for the next daily period.

The smallest unit of time in the pattern will be used to compute rollover periods, whether you choose days, half-days, hours, or even weeks or minutes. Rolling per second is not supported.

Log file rollover by file size

Rolls over in a configurable way for file size, to enable control over the maximum size of a log file. This has the effect of producing "back-up" log files within the rolling time period. For example, if the rollover is normally configured to occur daily, and the maximum log file size is exceeded within the period, a backup file will be created, and a new file started with the same time pattern in the filename.

Automatic backup log file cleanup

Scavenges old log files if configured to do so. Older log files will be deleted once a configurable number of log file backups have been created. The benefit is that the Appender itself takes some responsibility for managing the total size of all the log files it creates. Scavenging is performed by a daemon thread.

Backup log file compression

Compresses backup log files, if configured to do so, using either GZIP or ZIP. For the ZIP algorithm, there is also control over the level of compression, e.g. none, fastest, best, etc. NB Any log files left uncompressed at the time the Appender is closed will not subsequently be compressed: this is to prevent the Appender from chewing up resources on application start-up.

Log file rollover proactively at end of time period

Rolls files pro-actively at the end of a logging period, rather than reactively in response to a logging event dispatched by the application. This means that, at the end of a logging period (specified by the appender's DatePattern), the appender itself dispatches a logging event. This approach ensures that a file roll takes place safely even when the application is otherwise idle. Scheduled rolling is performed by a daemon thread.

Log file rollover at appender activation.

Rolls on startup, regardless of whether other rollover conditions are met, if configured to do so. This can be handy during application development, for example, where an application is stopped and started frequently. New log files will be created by the appender on each application restart and the old ones will be backed-up.

Internationalized time and date patterns

Date patterns can be specified for locales other than English, although English is the default. For example, if the German locale is specified ("de"), then the pattern "uuuu-MM-tt" can be used to specify what in the English locale ("en") would be specified as "yyyy-MM-dd" (for years-months-date).

More Information

There's additional useful information and discussion on my Blog.


If you find this useful, please drop me a mail.


This is an alternative to the standard Log4J AsyncAppender. It exists for a couple of reasons:

In trying to maximise throughput, I've come up with a slightly different solution to the same problem that AsyncAppender tries to address. The ActiveAsynchronousAppender blocks when the buffer is full, however it only appends a single LoggingEvent from its buffer at a time, before checking the buffer again. As soon as the buffer size drops below its maximum, the Appender ceases to block.

What are the benefits of the new code? As with the standard Log4J AsyncAppender, it depends in no small part upon the nature of the application. My own testing has shown that the ActiveAsynchronousAppender scales better as the thread count increases, and offers higher throughput even for very few threads.


Note that the ActiveAsynchronousAppender cannot be configured to discard LoggingEvents when the Appender's buffer is full.


See the ActiveAsynchronousAppender Javadoc for more detailed information, including sample configurations.


Download the ActiveAsynchronousAppender

NB This optionally depends upon the JSR-166 backport-util-concurrent backport and has been tested with version 3.1.

More Information

There's additional useful information and discussion on my Blog.


If you find this useful, please drop me a mail.