JDK-4960962 : (so) SocketChannel.close() does not close immediately when channel is registered
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2003-11-28
  • Updated: 2005-04-16
  • Resolved: 2005-04-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b33Fixed
Related Reports
Relates :  
JDK-6215050 - (so) SocketChannel created in CLOSE_WAIT and never cleaned up.. File Descriptor leak
Relates :  
JDK-6379892 - Remove @ignore from test since prerequisite is fixed
Relates :  
JDK-4957695 - URLJarFile.retrieve does not delete tmpFile on IOException
Relates :  
JDK-7130796 - (se) Selector.select may hang due to asynchronous close of socket in poll array [win]
Relates :  
JDK-6346658 - (se) Selector briefly spins when asynchronously closing a registered channel [win]
Description
SocketChannel.close() is not closing the underlying
socket when the channel is non blocking and registered with a 
Selector. [See comments for simple test case]

The problem seems to be in the socket pre/post close logic
and there are actually a couple of bugs I believe.

1. On Unix the dummy version of NativeDispatcher.preClose()
   is being called instead of the one in FileDispatcher. This
   is because SocketDispatcher extends NativeDispatcher instead
   of FileDispatcher. So, if you make SocketDispatcher extend
   FileDispatcher, this fixes the problem on Unix.

2. The problem also happens on Windows, presumably because the
   actual socket close should be happening (but is not) in the preClose()
   function.

Strangely, this seems to be a long standing issue. I can reproduce with
every release back to 1.4.0.
Comments
EVALUATION This is definitely a bug. Its effect is ameliorated by the fact that a closed registered socket will be truly closed once it's been completely deregistered. In a busy application that's managing many connections it's therefore unlikely that the delay between an invocation of a socket channel's close method and the actual closing of the underlying socket will be very long. This might explain why this bug has not yet been reported. The submitter's analysis and suggested fix for the Unix implementation appear to be correct. The fix for the Windows implementation requires further investigation; closing the socket in preClose method could bollix up the Windows selector logic. -- ###@###.### 2003/11/30
11-11-0196