1

If Log4j fails to write the log file due to a reason like disk-full or any other OS issue, it does not throw an exception.

How do we handle such a scenario, in my case, the java process should be self terminated if it fails to write the log file.

dGayand
  • 599
  • 1
  • 7
  • 15
  • 2
    usually, you make sure you never reach a disk full - you put in place monitoring tools, alerts, etc. to prevent such issues. For other IO errors, I must admit we never address these issues in our apps - we just assume logging frameworks DON'T fail – spi May 09 '19 at 12:17
  • 1
    @spi Yes there are monitoring tools already in place to generate alerts and notifications for those who are monitoring the system. But as a safety measure, the expected behaviour of the process is to self terminate in such scenarios. – dGayand May 09 '19 at 12:57
  • 1
    @spi The java file read/write operations throw checked exceptions, meaning the operation can be failed due to many reasons as it highly depends on the file system of the OS. Therefore I think the capability to track file write failures in logging framework like Log4J is something fundamental. – dGayand May 09 '19 at 13:02
  • then maybe create your own appender, maybe extending https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/WriterAppender.html, that would not swallow such errors... But I doubt this has any added value - nobody does that (14 years of Java, never saw such need...) – spi May 09 '19 at 13:38
  • I don't think you should get "inside" log4j. One way to handle this case, could be to create a "space monitor thread" in your program, to monitor the disk space (each 5 minutes?), and terminate your app if disk space gets below eg. 100M. To check the disk space, see https://stackoverflow.com/questions/1051295/how-to-find-how-much-disk-space-is-left-using-java – Daniele May 09 '19 at 19:30
  • Of course, another way is to roll you log files. They are either compressed (see the docs) or removed. – Daniele May 09 '19 at 19:32
  • 1
    @Daniele maybe compressing the files would not help to avoid IO exception - there is much more chances to have IOE when adding compression in the loop than adding a few raw bytes to an existing file. Btw, extending an API actually *is* the way to alter its behavior when it doesn't match your needs. – spi May 13 '19 at 14:15

0 Answers0