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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
