I/O cancellation issue with ServerSocketChannel

[Alan Bateman]

I think it's best to look at the changes for JDK-7133499 that we pushed 
to jdk9/dev in Jan 2014. This was focused on FileChannel (not the 
network channels) but uses a signal to preempt the blocked thread on OS 
X. This might be closer to what you need on AIX.

-Alan


On 03/06/2015 15:20, Langer, Christoph wrote:
>
> Hi Alan,
>
> on older AIX releases (5.3 and lower) I’m stumbling over the issue 
> that a Java process hangs when a ServerSocketChannel is accepting in 
> one thread and another thread is attempting to close the fd (hangs in 
> dup2()). This is the Java callstack:
>
> "Thread-0" #12 prio=5 os_prio=57 cpu=3.37 [reset 3.37] ms 
> elapsed=575.79 [reset 575.79] s allocated=17160 B (16.76 KB) [reset 
> 17160 B (16.76 KB)] defined_classes=2
>
> io= file i/o: 4077/48 B, net i/o: 0/0 B, files opened:0, socks 
> opened:0  [reset file i/o: 4077/48 B, net i/o: 0/0 B, files opened:0, 
> socks opened:0 ]
>
> tid=0x00000001853b8000 nid=0x1819 / 6169  ktid=2412747 runnable  
> [_thread_in_native (_at_safepoint), 
> stack(0x0000000185a55000,0x0000000185c55890)] [0x0000000185c54000]
>
> java.lang.Thread.State: RUNNABLE
>
>         at 
> sun.nio.ch.FileDispatcherImpl.preClose0(Ljava/io/FileDescriptor;)V(Native 
> Method)
>
>         at 
> sun.nio.ch.SocketDispatcher.preClose(Ljava/io/FileDescriptor;)V(SocketDispatcher.java:64)
>
>         at 
> sun.nio.ch.ServerSocketChannelImpl.implCloseSelectableChannel()V(ServerSocketChannelImpl.java:289)
>
>         - locked <0x00000000bad4db58> (a java.lang.Object)
>
>         at 
> java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel()V(AbstractSelectableChannel.java:234)
>
>         at 
> java.nio.channels.spi.AbstractInterruptibleChannel.close()V(AbstractInterruptibleChannel.java:115)
>
>         - locked <0x00000000bad4db18> (a java.lang.Object)
>
>         at 
> com.sap.cl.ServerSocketChannelAsyncCloseTest$1.run()V(ServerSocketChannelAsyncCloseTest.java:33)
>
>         at java.lang.Thread.run()V(Thread.java:812)
>
>    Locked ownable synchronizers:
>
>         - None
>
> "main" #1 prio=5 os_prio=57 cpu=1975.89 [reset 1975.89] ms 
> elapsed=582.97 [reset 582.97] s allocated=673352 B (657.57 KB) [reset 
> 673352 B (657.57 KB)] defined_classes=549
>
> io= file i/o: 2378532/24 B, net i/o: 0/0 B, files opened:4, socks 
> opened:1  [reset file i/o: 2378532/24 B, net i/o: 0/0 B, files 
> opened:4, socks opened:1 ]
>
> tid=0x000000018031a800 nid=0x102 / 258  ktid=2642125 runnable  
> [_thread_in_native (_at_safepoint), 
> stack(0x0000000180016000,0x0000000180216890)] [0x0000000180215000]
>
> java.lang.Thread.State: RUNNABLE
>
>         at 
> sun.nio.ch.ServerSocketChannelImpl.accept0(Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;[Ljava/net/InetSocketAddress;)I(Native 
> Method)
>
>         at 
> sun.nio.ch.ServerSocketChannelImpl.accept(Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;[Ljava/net/InetSocketAddress;)I(ServerSocketChannelImpl.java:422)
>
>         at 
> sun.nio.ch.ServerSocketChannelImpl.accept()Ljava/nio/channels/SocketChannel;(ServerSocketChannelImpl.java:250)
>
>         - locked <0x00000000bad4db48> (a java.lang.Object)
>
>         at 
> com.sap.cl.ServerSocketChannelAsyncCloseTest.main([Ljava/lang/String;)V(ServerSocketChannelAsyncCloseTest.java:45)
>
>    Locked ownable synchronizers:
>
>         - None
>
> The preClose0 method does a dup2 which hangs, waiting for accept in 
> the other thread to return which is working as designed on older AIX 
> releases. The behavior of dup2 was improved with AIX 6.1 and later 
> such that dup2 would return in this case. However, I found that in 
> this thread: 
> http://mail.openjdk.java.net/pipermail/nio-dev/2014-January/002500.html you 
> indicated that you had an idea on how to fix this and would come up 
> with a change proposal. What happened to that? In the current code 
> base, even of JDK9, I still find the same behavior.
>
> In my opinion one could just do the signaling in 
> ServerSocketChannelImpl.implCloseSelectableChannel() before one calls 
> the preClose() method. Is there any problem with that? Or do you have 
> a different solution?
>
> Thanks
>
> Christoph
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150603/1361360b/attachment.html>