S3TimeBasedRollingPolicy does not work as expected.

[vish91]

It looks like the S3TimeBasedRollingPolicy does not work as expected. When App shuts down, it leaves the last log file as a .tmp file and does not compress it as expected.
Example appender configuration

 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>logs/myapp.csv</file>
                <encoder>
                    <pattern>%d{"yyyy-MM-dd HH:mm:ss.SSSSSSSSS"},%msg%n</pattern>
                </encoder>
                <rollingPolicy class="ch.qos.logback.core.rolling.S3TimeBasedRollingPolicy">
                    <!-- Rollover every hour-->
                    <fileNamePattern>logs/accountID=${accountID}/audit.%d{yyyy-MM-dd_HH}.%i.csv.gz</fileNamePattern>
                    <totalSizeCap>4000KB</totalSizeCap>
                    <s3BucketName>dev</s3BucketName>
                    <s3FolderName>test-buck</s3FolderName>
                    <rolloverOnExit>true</rolloverOnExit>
                    <shutdownHookType>JVM_SHUTDOWN_HOOK</shutdownHookType>
                    <prefixTimestamp>false</prefixTimestamp>
                    <prefixIdentifier>true</prefixIdentifier>
                    <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                        <maxFileSize>10KB</maxFileSize>
                    </timeBasedFileNamingAndTriggeringPolicy>
                </rollingPolicy>
            </appender>

It should have rolled up the file Index and created a gz , but it didn't seem to have incremented the fileNameCounter or compressed it. Can someone confirm that this seems like a valid issue ? Have been looking in the code but actual process debugging is hard to capture to know what happens when onShutDown() calls the rollover() function.

[nilayspshah]

The File pattern you are using is: audit.%d{yyyy-MM-dd_HH}.%i.csv.gz

Your temp file is of the format

String tmpTarget = nameOfCompressedFile + System.nanoTime() + ".tmp";

The temp file created in your case, audit.2019-02-22_20.2.csv130..388.tmp will be stored as audit.2019-02-22.2.csv.gz as per convention
Since you already have a compressed file audit.2019-02-22.2.csv.gz, the tmp file could not be compressed

Was the audit.2019-02-22.2.csv.gz present from a previous run?
If not then it we need to check the ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP class as that is responsible for maintaining the currentPeriodsCounter, which is the %i we have in the file name pattern audit.%d{yyyy-MM-dd_HH}.%i.csv.gz