ppkarwasz commented on issue #3593: URL: https://github.com/apache/logging-log4j2/issues/3593#issuecomment-2813529986
> Potentially file output stream could be opened using NIO with `java.nio.file.StandardOpenOption.SYNC` option. It probably (need to test) will do the trick but I am wondering if there will be any noticeable performance penalty since it'll happen on every write I disagree, if the performance penalty was be negligible, that option would be on by default. Microsoft will probably solve the problem sooner or later, so I see no reason to modify the behavior for all Log4j Core users, however we can: - implement #2117 or at least part of it. The usage of NIO has the advantage of using the same `StandardOpenOption`s on UNIX and Windows. - add a configuration option to **all** [file appenders](https://logging.apache.org/log4j/2.x/manual/appenders/file.html) and [rolling file appenders](https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html) that accepts a comma-separated list of `StandardOpenOption`s. > Does [immediateFlush](https://logging.apache.org/log4j/2.x/manual/appenders.html#immediateFlush) not help? That would be really strange: `immediateFlush` should only flush the **Java** buffers (mostly our buffers, but some implementations of `OutputStream` also have buffers), while the problem here seems to be related to OS buffers that are not _synced_ with the underlying device. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
