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@qos.ch
http://qos.ch/mailman/listinfo/logback-user