[logback-dev] [JIRA] Created: (LBCORE-161) After a restart SizeAndTimeBasedFNATP uses incorrect sequence numbers for rollover files if compression is enabled

[Frank Bos (JIRA)]

After a restart SizeAndTimeBasedFNATP uses incorrect sequence numbers for rollover files if compression is enabled
------------------------------------------------------------------------------------------------------------------

                 Key: LBCORE-161
                 URL: http://jira.qos.ch/browse/LBCORE-161
             Project: logback-core
          Issue Type: Bug
          Components: Rolling
    Affects Versions: 0.9.24
            Reporter: Frank Bos
            Assignee: Logback dev list
            Priority: Minor


To reproduce this issue you can use a setup similar to the one used for LBCORE-131, but then use a filename pattern like "log.%d{yyyy-MM-dd}.%i.txt.gz" for the RollingPolicy.
This works fine as long as you don't restart the application that is doing the logging. The following files are created:

{noformat}
log.2010-08-02.0.txt.gz
log.2010-08-02.1.txt.gz
log.2010-08-02.2.txt     ( = active log file)
{noformat}

However, after a restart the following happens:

{noformat}
log.2010-08-02.0.txt.gz
log.2010-08-02.1.txt.gz
log.2010-08-02.1.txt     (!!)
log.2010-08-02.2.txt.gz
log.2010-08-02.3.txt.gz
log.2010-08-02.4.txt    (the active log file)
{noformat}

So there are now two versions of the logfile with index 1: one zipped and one unzipped. They do not contain the same messages!
Also the order of the messages in these logfiles is not what I expected. After the restart logback will first create the 'log.2010-08-02.1.txt' file and after that it will fill the existing 'log.2010-08-02.2.txt' file to the rollover size. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira