Hello Syvalta, This is related to issue LBCORE-109 [1]. It would be nice if a WriterAppender and derivatives could recuperate from a temporary failure. - Changes can be backward incompatible but within reason. - Attempts to recuperate from a failure should be done with parsimony. You could use a backoff mechanism: attempt if N seconds have elapses, in the subsequent attempt wait for 4*N, and in the third, wait for at least 16*N to elapse, and so forth until you reach 30 minutes as a maximum delay between attempts. - Do not do any buffering. If you do, you are likely to cause the applicaion to crash with OutOfMemoryException if there is no limit to the size of the buffer and it the buffer has a limit, then you can't guarantee that events won't be lost. It's way too much hassle for little benefit. - The patch would likely be accepted if it is easy to understand, if it has test cases and all existing test cases continue to pass. HTH, [1] http://jira.qos.ch/browse/LBCORE-109 Syvalta wrote:

Hi,

I noticed WriterAppender.subAppend stops appending if an IOException occurs during write. This is bit problematic if interruption is used as a cancellation mechanism (as suggested in JCiP). The problem is that if a thread happens to be logging at the time it is interrupted, logging (for that appender) will be ceased for the lifetime of the application (or until Logback is re-initialized). Additionally, if there are some transient errors, logging won't continue after recovery. At least it seems so, but I might be wrong.

I could provide a patch which changes the behavior, but it seems changes are non-trivial. I would be glad to receive some advice. - how backward compatible the changes should be? Can I remove methods, add abstract methods etc. or should backward compatibility be preserved (and if it is, does that increase the likelihood of the patch being applied)? - in what level at hierarchy this should be done? I have thought at WriterAppender, but that would require adding a method to create OutputStream, which subclasses would implement. Currently subclasses set writer to WriterAppender, so this would change it to the opposite. Another option would be to do it at FileAppender level, but I haven't investigated that option much yet. - should there be some "throttling", so that under persistent error state new outputstream would not be tried to be created in every logging call. I think so, perhaps some condition like "try in first 10 calls, but after that only every 30 sec). - should the log events be buffered under presence of error (of course limited amount with fifo or something)? - is there any chance that this kind of patch would be accepted? Do you see this kind of feature useful?

Hope you understand at least something from my post, I admit it is "bit" unclear :)

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch