[logback-dev] WriterAppender.subAppend behaviour in case of IOExceptions

[Ceki Gulcu]

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