[logback-user] Logback suddenly stopped logging

[Andreas Dejung]

Main problem for me is that if the thread got interrupted while it was writing to the file the message got lost and the appender was stopped. Changing this will be the important part. Actually acting and passing on the interruption is something else but I would guess not so important for most of the users.

-----Original Message-----
From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch] On Behalf Of Ralph Goers
Sent: Monday, 12 July 2010 11:16 PM
To: logback users list
Subject: Re: [logback-user] Logback suddenly stopped logging

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

_______________________________________________
Logback-user mailing list
Logback-user at qos.ch
http://qos.ch/mailman/listinfo/logback-user