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