How is that different than what it already does? Today we simply inspect the file extension and compress using that method after rollover.
Ralph > On May 5, 2022, at 9:47 AM, Priyanka Pardesi Ramachander > <[email protected]> wrote: > > 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 >> >>
