While useful I have concerns as to what the state of the file would be if the application dies. Also, is the file readable as it is being written? The RollingAppenders are already overly complicated so I am reluctant to add new features without doing something to simplify them.
Ralph > On May 5, 2022, at 12:34 AM, Matt Sicker <[email protected]> wrote: > > That sounds pretty useful to me. Using the existing compression > actions could make it so you can more easily support other compression > formats. > > On Wed, May 4, 2022 at 4:44 PM Alexander Lambert (HE/HIM) > <[email protected]> wrote: >> >> Hi all, >> >> We have a local modification to logging-log4j2/log4j-core that we are hoping >> to contribute back to open source. We modify the RollingFileAppender, adding >> a config option to compress the file as it is originally written instead of >> on rollover. The value of this is in reducing the volume of data required to >> be written to disk, improving performance. >> >> The summary of this change is as follows: >> >> * A new Boolean config option "compressOnWrite" for the >> RollingFileAppender. >> * If true, the log is written to e.g. a GZIPOutputStream instead of a >> FileOutputStream. >> * Any rollover compression action implied by the filePattern extension >> is skipped as the file is already compressed, and so only a rename is done. >> >> Right now our change only applies to the ".gz" compression type, but it >> would be possible to extend this functionality to the other compression >> methods - the file extension from the fileName could be used to detect this. >> The GZIP format is however especially appropriate for this feature: >> >> * No need to enforce an OnStartupTriggeringPolicy for the rollover, as it >> is valid to append new GZIP data to a closed GZIP file. >> >> Is there any reason that this enhancement would not be accepted into log4j? >> >> Many thanks, >> Alex
