[logback-user] Logback suddenly stopped logging

[Ceki Gülcü]

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