1

The configuration file of Log4j 2 is shown below,the following XML fragment defines policies that rollover the log when the log size reaches hundred megabytes

<RollingFile name="service" fileName="${log_path}/service/FDI.log"
                         filePattern="${log_path}/service/$${date:yyyyMMdd}/proc-FDI-service-${env:HOST_IP}-%d{yyyyMMdd}-%i.log.zip"
                         filePermissions="rwxrwxrwx"
                         >

        <PatternLayout>
                <Pattern>%d [%t] [%X{FLOWNO}] [%X{IP}] (%c.%M:%L) [%-5p] - %m%n</Pattern>
        </PatternLayout>

        <Policies>                               
                <TimeBasedTriggeringPolicy interval="1" modulate="true" />                               
                <SizeBasedTriggeringPolicy size="100MB"/>
        </Policies>

        <DefaultRolloverStrategy max="999" compressionLevel="9"/>
</RollingFile>

Indeed, a compressed file was generated.

Why still is it 100MB after compression?

-rwxrwxrwx 1 dcits dcits 101M Jan 16 17:00 proc-FDI-service--20220116-3.log.zip
hgxzn
  • 11
  • 2
  • 1
    The policy is about the file size, which is compressed, not about the uncompressed log size. I'm not sure why you think it would or should do this on the uncompressed file. – Mark Rotteveel Jan 16 '22 at 10:33
  • My understanding is that when the log file reaches 100MB, the roll is triggered,and then the log file will be compressed,and my question is why still is 100MB after compression – hgxzn Jan 16 '22 at 10:52
  • That would be inefficient, I would rather think it compresses while logging (though I haven't checked if Log4J actually does that). – Mark Rotteveel Jan 16 '22 at 10:57
  • Mark, Log4j checks the size of the current (uncompressed) file `FDI.log` so the size of the rotated ones should be smaller. My guess is that the configuration was changed many times and at one point `FDI.log` was allowed to grow much larger than 100MB. – Piotr P. Karwasz Jan 16 '22 at 22:35

0 Answers0