Bertrand Renuart created LOGBACK-1472:
-----------------------------------------

             Summary: RollingFileAppender unable to keep appending to current 
file when rollover failed
                 Key: LOGBACK-1472
                 URL: https://jira.qos.ch/browse/LOGBACK-1472
             Project: logback
          Issue Type: Bug
          Components: logback-core
    Affects Versions: 1.2.3
            Reporter: Bertrand Renuart
            Assignee: Logback dev list


It may happen the {{RollingFileAppender}} becomes unable to keep appending 
events into the current file when {{rollover()}} failed.

The {{RollingFileAppender#rollover()}} method looks as follows:
{code:java}
public void rollover() {
  lock.lock();
  try {
    this.closeOutputStream();
    attemptRollover();
    attemptOpenFile();
  } finally {
    lock.unlock();
  }
}{code}
The method starts by closing the current output stream which sets the 
{{outputStream}} protected field to {{null}} until the file is reopened again. 
It then tries to rotate and reopen the file before exiting. However, if one of 
these two methods throw an unexpected exception, the {{outputStream}} field is 
left to {{null}}. 

This field is also left to {{null}} if the {{attemptOpenFile()}} method fails 
to reopen the new current file as returned by the rolling policy. This can 
happen if, for instance, the file system is not available (remote fs?), or if 
the policy returns a file located somewhere we don't have enough permissions, 
etc...

The next time an event is received, the {{writeBytes}} method will throw a 
{{NullPointerException}}. *Unfortunately, this case is not expected and there 
is nothing to attempt to recover from it. The appender now starts dropping all 
events until the triggeringPolicy asks for a new rollover.*

 

Comments in the {{attemptRollover}} method say that in case of exception, it 
should keep the same file but in append mode since it is safer to keep 
appending in an _outdated_ file instead of dropping events.

Unfortunately, as mentioned above, the file output stream as been closed 
already, and an attempt is made to reopen it under the _new_ filename instead.

 



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev

Reply via email to