[logback-dev] [JIRA] (LOGBACK-1472) RollingFileAppender unable to keep appending to current file when rollover failed

[QOS.CH (JIRA)]

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)