[logback-user] Logback suddenly stopped logging

Joern Huxhorn jhuxhorn at googlemail.com
Mon Jul 12 14:06:00 CEST 2010


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



More information about the Logback-user mailing list