JDK-6638290 : (dc) Data corruption with asynchronous close
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 6u4
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2007-12-06
  • Updated: 2024-04-12
  • Resolved: 2018-04-19
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8198562 - (ch) Separate blocking and non-blocking code paths (part 1)
Relates :  
JDK-6285901 - (so) Data corruption with asynchronous close (Solaris/Linux)
Description
DatagramChannelImpl and ServerSocketChannelImpl both suffer from the same problem of aysnchronous close as described in 6285901. Of course, with ServerSocketChannel it is calling accept and not read/write.
Comments
The changes for JDK-8198562 have replaced the async close implementation so I don't think the issue here is an issue any longer (except Windows where we have no way to close a connection without releasing the SOCKET). I think we can close this issue.
28-02-2018
EVALUATION As discussed with submitter, the changes for 6285901 addressed SocketChannel only and the other channel types need to be updated too. There are feasibility issues to resolving this on Windows for all channel types and that is tracked by another bug.
06-12-2007