I/O cancellation issue with ServerSocketChannel

[Langer, Christoph]

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/dc1425f9/attachment-0001.html>