logging-log4j2

logging-log4j2 copied to clipboard

Description

Both the RollingFileAppender and RollingRandomAccessFileAppender plugins offer a boolean flag, immediateFlush, to allow for immediate flushing of buffers when writing data. This option is ultimately discarded when creating the corresponding RollingFileManager and RollingRandomAccessFileManager instances.

Configuration

Version: 2.x and main

Operating system: all

JDK: all

Logs

n/a

Reproduction

The amusing part is that we have tons of tests that set immediateFlush to true or false, yet none of these tests verify that it does anything.

The property is used in AbstractOutputStreamAppender#directEncodeEvent and AbstractOutputStreamAppender#writeByteArrayToManager. As far as I can tell, it is not ignored.

Which is why static analysis is complaining about what exactly?

The SAST tool is right: RollingFileManager doesn't do anything with the property, but RollingFileAppender does.

It would be useful to remove the property from RollingFileManager since it is not used.

Oh, then consider this a bug for that. Unused fields are a bug.

Hi,

RandomAccessFile 

FileChannel channel = randomAccessFile.getChannel();
randomAccessFile.write();
channel.force(true);

Use the force method，the file be updated in real time. But affects performance. Log4j2，not use the force method.

Rewrite RollingRandomAccessFileManager and RandomAccessFileManager flush method. Add the code above.

@jvz,

I investigated the effects of flush() on the FileAppender a little bit further and it is a no-op in FileOutputStream (the output stream does not use any Java buffers, so there is nothing to flush). So I would propose to:

• remove immediateFlush from FileAppender.Builder and similar,
• remove any references to immediateFlush in the documentation.

@ppkarwasz sounds like a good idea to me!

Actually there is another usage of immediateFlush: resource managers use a ByteBuffer to format each log event.

If immediateFlush is true, the byte buffer is flushed at each event.