JDK-6204940 : UDP DatagramSocket close causes delayed IOException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.2_06
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-12-07
  • Updated: 2011-12-23
  • Resolved: 2005-02-11
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.
1.4.2_08 b02Fixed
A udp socket in the middle of a sock.receive() is closed (sock.close()
is called) and an IOException is raised after about 6 minutes.

Here's the code snippet :

      try {
		receiving = true;
	      receiving = false;
      catch (SocketTimeoutException ste) {
	    receiving = false;
	    throw ste;
      catch (IOException ioe) {
	    receiving = false;
	    socket = null;

The udp socket is receiving rtp data and socket.close() is called from
another thread. By the time socket.close() is called, the rtp sender may have stopped sending the data or even
closed the rtp socket (Cu can not control what is done on the sender

In any case, calling socket.close() should raise an IOException
immediately. But we're getting the exception close to 6 minutes after
the call to close(). Suggesting the socket.receive() was stuck for
some reason.

This scenario seems to be acceptible with a TCP socket where sock.close() still
keeps the socket open for a possible receive call [TCP FIN means 'done
sending' not receiving]. But with UDP, this seems to be a problem.
###@###.### 2004-12-07 06:52:58 GMT

EVALUATION As there is no test case, I could not reproduce the problem. From the description: There are two threads involved on one UDP socket. One thread is doing a while-loop on receive() and the other thread is closing the socket. Since the reported problem occurs at random time, we can suspect only the receive() to wait for data availability. Then, how it times out after 6 minutes ? At Java level the socket is closed and the status would be isClosed()==true. If the same port is used by the server to send data, the receive() comes out successfully and on the next time the SocketException(socket closed) would be thrown. In the PlainDatagramSocketImpl, timeout is used before recvfrom(). In Win32 WinSock2, setsockopt(SOL_SOCKET, SO_RCVTIMEO) can be used to interrupt the recvfrom() blocking call. ###@###.### 2004-12-22 15:21:42 GMT The receive() native implementation uses NET_Timeout() and recvfrom() when a timeout value is specified on the socket. This can introduce a time window/gap inbetween these two calls. When another thread updates the socket's fd, it could cause inconsistance fd to be used in this receive() thread. To fix this, the socket fd is fetched again and validated before proceeding with recvfrom(). ###@###.### 2005-2-03 03:53:35 GMT