Hi All, How about this approach instead?.. -> A new Boolean config option "fileCompression" for the RollingFileAppender. -> If true, the log is written to FileOutputStream (as usual). -> And at the time of rollover, compress the file (as .gz, .zip, etc) and delete the original file. In case of any abnormal termination of the app, once it is up again (if filePattern extension is still the same) it will continue to log to the same file.
Sincerely, Priyanka On Thu, May 5, 2022 at 3:27 PM Ralph Goers <[email protected]> wrote: > 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 > >
