United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6204940 UDP DatagramSocket close causes delayed IOException
6204940 : UDP DatagramSocket close causes delayed IOException

Details
Type:
Bug
Submit Date:
2004-12-07
Status:
Resolved
Updated Date:
2011-12-23
Project Name:
JDK
Resolved Date:
2005-02-11
Component:
core-libs
OS:
windows_2000
Sub-Component:
java.net
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_06
Fixed Versions:
1.4.2_08

Related Reports

Sub Tasks

Description
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;
          	socket.receive(packet);
	      receiving = false;
      }
      catch (SocketTimeoutException ste) {
	    receiving = false;
	    throw ste;
      }
      catch (IOException ioe) {
	    receiving = false;
	    socket = null;
          break;
      }

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
side).

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

Comments
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
2004-12-22


Hardware and Software, Engineered to Work Together