[logback-user] Logback suddenly stopped logging

[Ceki Gülcü]

I believe that the consumption of the interrupt flag by java.io code
*only* occurs on Solaris, even then, you can prevent that behavior by
starting the JVM with the -XX:-UseVMInterruptibleIO option.

Given that the issue is Solaris-specific and preventable with the
-XX:-UseVMInterruptibleIO option, and given that the programming style
for thread synchronization using interrupt() is in my opinion quite
lame, I am tempted to ignore this issue. However, it is also true that
some classes belonging to the JDK, i.e. PrintStream, invoke
Thread.interrupt() after catching an InterruptedIOException. It
follows that calling Thread.interrupt() looks like the sanctioned
coding style.

More pragmatically, as of logback version 0.9.19 released on March
24th 2010, FileAppender and derived classes will recover from
temporary IO problems. The message at the origin of this thread is
dated December 16th 2009 pre-dating 0.9.19. In other words, I think
0.9.19 already addressed the original issue.

It looks like none of the reporters of this issue, including
LBCORE-155, do suffer from the loss of the Thread interrupt signal
but are actually worried about the noise generated by the
InterruptedIOException in status messages. In the context of
FileAppender and its existing recovery capability, calling
Thread.interrupt() within catch clauses as done by Joern in [1] or as
done in log4j 1.2.16, seems essentially useless even if they follow the
sanctioned coding paradigm.

Regarding LBCORE-155, since Daniel seems to complain about the
logback exceptions printed on the console as status messages, I think
not printing the stack trace of InterruptedIOExceptions is the desired
approach in his particular case.

Cheers,

On 06/07/2010 6:23 AM, Joern Huxhorn wrote:
> Argh!.
>
> You are, of course, right! I guess it must've been the heat... :D
>
> Thanks,
> Joern.
>
> On 06.07.2010, at 00:54, Andreas Dejung wrote:
>
>> Looks fine to me except line 93 should that not be
>> current=current.getCause();
>> otherwise you would always get the first cause of the first throwable
>> t wouldn’t you ?
>> Cheers Andy
>> *From:* logback-user-bounces at qos.ch
>> <mailto:logback-user-bounces at qos.ch>
>> [mailto:logback-user-bounces at qos.ch] *On Behalf Of *Joern Huxhorn
>> *Sent:* Monday, 5 July 2010 11:58 PM
>> *To:* logback users list
>> *Subject:* Re: [logback-user] Logback suddenly stopped logging
>> OMG, I wasn't aware of such an issue with IOException.
>> I guess that my code is suffering from the same issue. I've just
>> implemented a small utility class for later use.
>> http://github.com/huxi/sulky/blob/master/sulky-io/src/main/java/de/huxhorn/sulky/io/ThreadInterruptionSafeguard.java
>> Please give the code a quick look and tell me if I forgot something or
>> missed some point.
>> Thanks,
>> Joern.
>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user