[JIRA] Created: (LBCORE-152) When your application is stopped and restarted, logging will not continue at the correct location, i.e. at the largest index number for the current period.
When your application is stopped and restarted, logging will not continue at the correct location, i.e. at the largest index number for the current period. ----------------------------------------------------------------------------------------------------------------------------------------------------------- Key: LBCORE-152 URL: http://jira.qos.ch/browse/LBCORE-152 Project: logback-core Issue Type: Sub-task Components: Rolling Affects Versions: 0.9.20 Reporter: David Gonzalez Assignee: Logback dev list As the online manual says (http://logback.qos.ch/manual/appenders.html) : "When your application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period.". This mean that the following steps occured : - You have a log.trc current log file - When rolling, as the <fileNamePattern> defined is <fileNamePattern>log_%i.log.zip</fileNamePattern>, archived log filed are created with the index %i starting at Zero. - If current index is 3 when application is stopped, then restarting index is 4 and next archived log file to be created is log_4.log.zip But this does not occure. Unfortunately the new archived log file with index equals to 4 is not created and you see a file with a weird name log_tmp<nanosseconds>.log created. The reason has to be linked to LBCORE-131, current period index is not properly managed then when system is restarted this index is newly set to Zero and not 4. As system tries to create log_0.log.zip file, system does test that this file exists and stops. Temporary file tmp<nanos> which has to be saved as archived log file stays created (should have been deleted after archived log file creation successed). As LBCORE-131 gives a fix, this fix should be improve in order to test also if current index period has to be increase because archived lof file in COMPRESS MODE already exists. -- 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
[ http://jira.qos.ch/browse/LBCORE-152?page=com.atlassian.jira.plugin.system.i... ] David Gonzalez commented on LBCORE-152: --------------------------------------- My analysis was too quick. LBCORE-131's fix also solve the problem in COMPRESS MODE. LBCORE-131 and LBCORE-152 are two results of the same bug (problem to manage currentPeriodsCounter)
When your application is stopped and restarted, logging will not continue at the correct location, i.e. at the largest index number for the current period. -----------------------------------------------------------------------------------------------------------------------------------------------------------
Key: LBCORE-152 URL: http://jira.qos.ch/browse/LBCORE-152 Project: logback-core Issue Type: Sub-task Components: Rolling Affects Versions: 0.9.20 Reporter: David Gonzalez Assignee: Ceki Gulcu
As the online manual says (http://logback.qos.ch/manual/appenders.html) : "When your application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period.". This mean that the following steps occured : - You have a log.trc current log file - When rolling, as the <fileNamePattern> defined is <fileNamePattern>log_%i.log.zip</fileNamePattern>, archived log filed are created with the index %i starting at Zero. - If current index is 3 when application is stopped, then restarting index is 4 and next archived log file to be created is log_4.log.zip But this does not occure. Unfortunately the new archived log file with index equals to 4 is not created and you see a file with a weird name log_tmp<nanosseconds>.log created. The reason has to be linked to LBCORE-131, current period index is not properly managed then when system is restarted this index is newly set to Zero and not 4. As system tries to create log_0.log.zip file, system does test that this file exists and stops. Temporary file tmp<nanos> which has to be saved as archived log file stays created (should have been deleted after archived log file creation successed). As LBCORE-131 gives a fix, this fix should be improve in order to test also if current index period has to be increase because archived lof file in COMPRESS MODE already exists.
-- 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
[ http://jira.qos.ch/browse/LBCORE-152?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu resolved LBCORE-152. ------------------------------- Resolution: Duplicate According to the report this issue is a duplicate of LBCORE-131 which was fixed recently.
When your application is stopped and restarted, logging will not continue at the correct location, i.e. at the largest index number for the current period. -----------------------------------------------------------------------------------------------------------------------------------------------------------
Key: LBCORE-152 URL: http://jira.qos.ch/browse/LBCORE-152 Project: logback-core Issue Type: Sub-task Components: Rolling Affects Versions: 0.9.20 Reporter: David Gonzalez Assignee: Ceki Gulcu
As the online manual says (http://logback.qos.ch/manual/appenders.html) : "When your application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period.". This mean that the following steps occured : - You have a log.trc current log file - When rolling, as the <fileNamePattern> defined is <fileNamePattern>log_%i.log.zip</fileNamePattern>, archived log filed are created with the index %i starting at Zero. - If current index is 3 when application is stopped, then restarting index is 4 and next archived log file to be created is log_4.log.zip But this does not occure. Unfortunately the new archived log file with index equals to 4 is not created and you see a file with a weird name log_tmp<nanosseconds>.log created. The reason has to be linked to LBCORE-131, current period index is not properly managed then when system is restarted this index is newly set to Zero and not 4. As system tries to create log_0.log.zip file, system does test that this file exists and stops. Temporary file tmp<nanos> which has to be saved as archived log file stays created (should have been deleted after archived log file creation successed). As LBCORE-131 gives a fix, this fix should be improve in order to test also if current index period has to be increase because archived lof file in COMPRESS MODE already exists.
-- 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
participants (2)
-
Ceki Gulcu (JIRA) -
David Gonzalez (JIRA)