[logback-user] Logback suddenly stopped logging

[Ralph Goers]

Thread.interrupt works fine in modern JVMs including Linux. In fact, Our workaround to checking for changes to logback.xml was to write a s ServletContextListener that sleeps for some amount of time and then checks the timestamp. However, during shutdown it would hang waiting for the poll interval to complete so we added a call to interrupt to cause it to wake immediately. This works fine on every platform we run it on.

Concurrency in Practice by Brian Goetz has a good writeup on how thread interruption works and what it guarantees and what it doesn't.

Ralph

On Jul 12, 2010, at 6:05 AM, Ceki Gülcü wrote:

> 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.
> 
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user