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:

public void rollover() {
  lock.lock();
  try {
    this.closeOutputStream();
    attemptRollover();
    attemptOpenFile();
  } finally {
    lock.unlock();
  }
}

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 has been closed already, and an attempt is made to reopen it under the new filename instead.