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@qos.ch [mailto:logback-user-bounces@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/I... : "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@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user