[logback-user] Logback suddenly stopped logging

[Ceki Gülcü]

Hi Joern, Hi Robert,

Thank you both for your comments.

To my understanding, Thread.interrupt is an intrathread communication
mechanism which does not work on most environments, e.g. Windows and
Linux. Thus, most code would use intra-thread communication mechanism
*other* than Thread.interrupt. As far as my personal experience goes,
I used Thread.interrupt in 1996, the second week after learning
Java. It did not work and I have never used Thread.interrupt ever
since. In books covering concurrency, whenever sample code tried to be
Thread.interrupt resistant in addition to proving its intended
intra-thread communication service, quickly became intractable.
Moreover, the cost of actually testing proper support for
Thread.interrupt in logback would be considerable.

I think it is saner to say that logback does NOT support
Thread.interrupt. We will however add such support if a logback user
suffers from the loss of the Thread.interrupt signal. I just want to
ascertain that the need is really there before making the
investment. The investment is not only sprkinling the appropriate
catch blocks with Thread.interrupt but also creating the necessary
test cases making sure that the code actually works.

On 08/07/2010 12:24 PM, Joern Huxhorn wrote:
> I agree with Robert.
>
> According to
> http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/api/java/io/InterruptedIOException.html
> :
> "An |InterruptedIOException| is thrown to indicate that an input or
> output transfer has been terminated because the thread performing it was
> interrupted."
>
> This means that the threads interrupted state should indeed be restored
> after catching such an event.
>
> I can't emphasize enough how stupid I consider the existence of this
> issue - but obviously all code should be checked for this. I'm
> especially annoyed since IOUtils.closeQuietly() is broken, too, because
> it ignores this...
>
> I wouldn't go down the road of "it's just Solaris" since this is
> documented behavior that we obviously just weren't aware of.
>
> Cheers,
> Joern.
>
> On 08.07.2010, at 10:41, Robert Elliot wrote:
>
>>> 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.
>>
>> My understanding from reading Java Concurrency in Practice (pp 92-94
>> and 138-144) is that it is more than sanctioned coding style - it's
>> vital to correct working of the interrupted thread model, and a well
>> behaved consumer of InterruptedException must restore the interrupted
>> status unless it is going to propagate the exception or is sure that
>> the thread will terminate immediately after catching it.