Log4j 1.2 is old, but still in very wide use. It works and for most applications performance is good enough. For log-intensive applications there are some tricks. The AsyncAppender can act as a buffer between the application and slower loggers (including FileAppender in some cases – be sure to use a large buffer though!), but that only helps for short bursts.
The FileAppender itself and its subclasses can work in buffered or immediate mode. Buffered mode is enabled with the BufferedIO parameter. When true the appender uses an 8k buffer and flushes the entire buffer to disk when it is full. This is much faster than the default operation, which flushes immediately for every log event. The disadvantage is that log entries are delayed and unless the appender is closed cleanly (a problem with most applications I’ve seen) many log events may be lost.
I have written a flush appender that can help. It can flush the file appenders when an event with high severity is logged (ensuring that errors are written to disk immediately). It can also flush and convert the file appenders to immediate mode when a specific message is logged, for example “Shutting down…”. That way no messages are lost during the shutdown process. The appender is available from Github and Maven Central (name.wramner.log4j:FlushAppender).
During migration from Oracle 11gR2 to 12c we encountered a weird error. We had a very complex select, that used WITH clauses, some with GROUP BY. It works in 11g, but with 12c it fails with:
ORA-00979: not a GROUP BY expression
Apparently something has changed. We have not yet found the root cause of the issue, but if we add
/*+ materialize */ to the selects in the WITH clauses it works!
If the query is simplified a bit the hint is not required, even though it still has the same GROUP BY clauses. Smells like a bug.
EDIT: reported to Oracle as Bug 20887136 – ORA-00979 AFTER UPGRADE TO 188.8.131.52.