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
[email protected]
http://qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
