Re: [logback-user] Logback suddenly stopped logging
I had the same problem and I think I know why J Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way. If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol) And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j I think it should be solved the same why } catch (InterruptedIOException iioe){ //give the thread a changes to act on interruption and then carry on Thread.currentThread().interrupt(); } catch (IOException ioe) { // as soon as an exception occurs, move to non-started state // and add a single ErrorStatus to the SM. this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); } I could not find the jira entry mentioned in this thread therefore I write it here J BTY the jvm option -XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that's only a workaround and not solving the problem ;) Cheers Andy
Andreas, Thank you for this report. I believe the same issue was reported in http://jira.qos.ch/browse/LBCORE-155 Cheers, On 05/07/2010 8:27 AM, Andreas Dejung wrote:
I had the same problem and I think I know why J
Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way.
If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol)
And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j
I think it should be solved the same why
} *catch* (InterruptedIOException iioe){
//give the thread a changes to act on interruption and then carry on
Thread.currentThread().interrupt();
} *catch* (IOException ioe) {
// as soon as an exception occurs, move to non-started state
// and add a single ErrorStatus to the SM.
*this*.started = *false*;
addStatus(*new* ErrorStatus("IO failure in appender", *this*, ioe));
}
I could not find the jira entry mentioned in this thread therefore I write it here J
BTY the jvm option –XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that’s only a workaround and not solving the problem ;)
Cheers Andy
OMG, I wasn't aware of such an issue with IOException. I guess that my code is suffering from the same issue. I've just implemented a small utility class for later use. http://github.com/huxi/sulky/blob/master/sulky-io/src/main/java/de/huxhorn/s... Please give the code a quick look and tell me if I forgot something or missed some point. Thanks, Joern. On 05.07.2010, at 08:27, Andreas Dejung wrote:
I had the same problem and I think I know why J
Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way.
If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol) And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j
I think it should be solved the same why
} catch (InterruptedIOException iioe){ //give the thread a changes to act on interruption and then carry on Thread.currentThread().interrupt(); } catch (IOException ioe) { // as soon as an exception occurs, move to non-started state // and add a single ErrorStatus to the SM.
this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); }
I could not find the jira entry mentioned in this thread therefore I write it here J
BTY the jvm option –XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that’s only a workaround and not solving the problem ;)
Cheers Andy
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Looks fine to me except line 93 should that not be current=current.getCause(); otherwise you would always get the first cause of the first throwable t wouldn't you ? Cheers Andy From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Joern Huxhorn Sent: Monday, 5 July 2010 11:58 PM To: logback users list Subject: Re: [logback-user] Logback suddenly stopped logging OMG, I wasn't aware of such an issue with IOException. I guess that my code is suffering from the same issue. I've just implemented a small utility class for later use. http://github.com/huxi/sulky/blob/master/sulky-io/src/main/java/de/huxho rn/sulky/io/ThreadInterruptionSafeguard.java Please give the code a quick look and tell me if I forgot something or missed some point. Thanks, Joern. On 05.07.2010, at 08:27, Andreas Dejung wrote: I had the same problem and I think I know why J Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way. If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol) And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j I think it should be solved the same why } catch (InterruptedIOException iioe){ //give the thread a changes to act on interruption and then carry on Thread.currentThread().interrupt(); } catch (IOException ioe) { // as soon as an exception occurs, move to non-started state // and add a single ErrorStatus to the SM. this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); } I could not find the jira entry mentioned in this thread therefore I write it here J BTY the jvm option -XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that's only a workaround and not solving the problem ;) Cheers Andy _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Argh!. You are, of course, right! I guess it must've been the heat... :D Thanks, Joern. On 06.07.2010, at 00:54, Andreas Dejung wrote:
Looks fine to me except line 93 should that not be current=current.getCause();
otherwise you would always get the first cause of the first throwable t wouldn’t you ?
Cheers Andy
From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Joern Huxhorn Sent: Monday, 5 July 2010 11:58 PM To: logback users list Subject: Re: [logback-user] Logback suddenly stopped logging
OMG, I wasn't aware of such an issue with IOException.
I guess that my code is suffering from the same issue. I've just implemented a small utility class for later use. http://github.com/huxi/sulky/blob/master/sulky-io/src/main/java/de/huxhorn/s...
Please give the code a quick look and tell me if I forgot something or missed some point.
Thanks, Joern.
I believe that the consumption of the interrupt flag by java.io code *only* occurs on Solaris, even then, you can prevent that behavior by starting the JVM with the -XX:-UseVMInterruptibleIO option. 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. More pragmatically, as of logback version 0.9.19 released on March 24th 2010, FileAppender and derived classes will recover from temporary IO problems. The message at the origin of this thread is dated December 16th 2009 pre-dating 0.9.19. In other words, I think 0.9.19 already addressed the original issue. It looks like none of the reporters of this issue, including LBCORE-155, do suffer from the loss of the Thread interrupt signal but are actually worried about the noise generated by the InterruptedIOException in status messages. In the context of FileAppender and its existing recovery capability, calling Thread.interrupt() within catch clauses as done by Joern in [1] or as done in log4j 1.2.16, seems essentially useless even if they follow the sanctioned coding paradigm. Regarding LBCORE-155, since Daniel seems to complain about the logback exceptions printed on the console as status messages, I think not printing the stack trace of InterruptedIOExceptions is the desired approach in his particular case. Cheers, On 06/07/2010 6:23 AM, Joern Huxhorn wrote:
Argh!.
You are, of course, right! I guess it must've been the heat... :D
Thanks, Joern.
On 06.07.2010, at 00:54, Andreas Dejung wrote:
Looks fine to me except line 93 should that not be current=current.getCause(); otherwise you would always get the first cause of the first throwable t wouldn’t you ? Cheers Andy *From:* logback-user-bounces@qos.ch <mailto:logback-user-bounces@qos.ch> [mailto:logback-user-bounces@qos.ch] *On Behalf Of *Joern Huxhorn *Sent:* Monday, 5 July 2010 11:58 PM *To:* logback users list *Subject:* Re: [logback-user] Logback suddenly stopped logging OMG, I wasn't aware of such an issue with IOException. I guess that my code is suffering from the same issue. I've just implemented a small utility class for later use. http://github.com/huxi/sulky/blob/master/sulky-io/src/main/java/de/huxhorn/s... Please give the code a quick look and tell me if I forgot something or missed some point. Thanks, Joern.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
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.
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
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.
As far as I'm aware, the behavior of Thread.interrupt is defined by the JLS and is not optional. That said it sounds like there may be some misunderstanding about its function. Unless a thread is sleeping or blocked on some operation, interrupting it really only sets a flag on the thread which code is free to ignore if it so chooses. In other words, typically interrupting a thread will not do anything at all unless the code running in the thread is written in a way which is responsive to interrupts. Java Concurrency in Practice is indeed the bible on these sorts of issues; and describes these idioms thoroughly, as well as the well established practice of resetting the interrupted status of the thread after swallowing an InterruptedException. The latter is also described here by the author of JCIP: http://www.ibm.com/developerworks/java/library/j-jtp05236.html -----Original Message----- From: Ceki Gülcü [mailto:ceki@qos.ch] Sent: Monday, July 12, 2010 9:06 AM To: logback users list Subject: Re: [logback-user] Logback suddenly stopped logging 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
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
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
I just tried few things with concurrency, and observed that if a Thread is interrupted with Future.cancel(true); all the logging does get stopped. Is this issue again related with same Interrupt? Is there any workaround for this? I am using 1.1.2 classic and core -- View this message in context: http://logback.10977.n7.nabble.com/Re-Logback-suddenly-stopped-logging-tp323... Sent from the Users mailing list archive at Nabble.com.
I guess you can catch InterupttedException and do any logging before setting the interrupted state on the thread again. -- View this message in context: http://logback.10977.n7.nabble.com/Re-Logback-suddenly-stopped-logging-tp323... Sent from the Users mailing list archive at Nabble.com.
I've just realized that the current JVM on Mac is also throwing InterruptedIOException ERROR: Aborted Maven execution for InterruptedIOException java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at hudson.maven.MavenProcessFactory$SocketHandler$AcceptorImpl.accept(MavenProcessFactory.java:167) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) So this issue isn't only related to Solaris anymore. Just FYI, 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
Thank you for sharing this info. On 12/07/2010 2:06 PM, Joern Huxhorn wrote:
I've just realized that the current JVM on Mac is also throwing InterruptedIOException
ERROR: Aborted Maven execution for InterruptedIOException java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at hudson.maven.MavenProcessFactory$SocketHandler$AcceptorImpl.accept(MavenProcessFactory.java:167) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637)
So this issue isn't only related to Solaris anymore.
Just FYI, 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
I was just wondering: Doesn't this make commons-io IOUtils.closeQuietly really risky? Cheers, Jörn. On 05.07.2010, at 08:27, Andreas Dejung wrote:
I had the same problem and I think I know why J
Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way.
If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol) And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j
I think it should be solved the same why
} catch (InterruptedIOException iioe){ //give the thread a changes to act on interruption and then carry on Thread.currentThread().interrupt(); } catch (IOException ioe) { // as soon as an exception occurs, move to non-started state // and add a single ErrorStatus to the SM.
this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); }
I could not find the jira entry mentioned in this thread therefore I write it here J
BTY the jvm option –XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that’s only a workaround and not solving the problem ;)
Cheers Andy
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (8)
-
Andreas Dejung -
Becker, Thomas -
Ceki Gülcü -
diroussel -
Joern Huxhorn -
Kedar -
Ralph Goers -
Robert Elliot