236

3 questions:

  1. What is the difference between connection and read timeout for sockets?

  2. What does connection timeout set to "infinity" mean? In what situation can it remain in an infinitive loop? and what can trigger that the infinity-loop dies?

  3. What does read timeout set to "infinity" mean? In what situation can it remain in an infinitive loop? and what can trigger that the infinity-loop dies?

James McMahon
  • 48,506
  • 64
  • 207
  • 283
corgrath
  • 11,673
  • 15
  • 68
  • 99

2 Answers2

294
  1. What is the difference between connection and read timeout for sockets?

The connection timeout is the timeout in making the initial connection; i.e. completing the TCP connection handshake. The read timeout is the timeout on waiting to read data1. If the server (or network) fails to deliver any data <timeout> seconds after the client makes a socket read call, a read timeout error will be raised.

  1. What does connection timeout set to "infinity" mean? In what situation can it remain in an infinitive loop? and what can trigger that the infinity-loop dies?

It means that the connection attempt can potentially block for ever. There is no infinite loop, but the attempt to connect can be unblocked by another thread closing the socket. (A Thread.interrupt() call may also do the trick ... not sure.)

  1. What does read timeout set to "infinity" mean? In what situation can it remain in an infinite loop? What can trigger that the infinite loop to end?

It means that a call to read on the socket stream may block for ever. Once again there is no infinite loop, but the read can be unblocked by a Thread.interrupt() call, closing the socket, and (of course) the other end sending data or closing the connection.

1 - It is not ... as one commenter thought ... the timeout on how long a socket can be open, or idle.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
11

These are timeout values enforced by JVM for TCP connection establishment and waiting on reading data from socket.

If the value is set to infinity, you will not wait forever. It simply means JVM doesn't have timeout and OS will be responsible for all the timeouts. However, the timeouts on OS may be really long. On some slow network, I've seen timeouts as long as 6 minutes.

Even if you set the timeout value for socket, it may not work if the timeout happens in the native code. We can reproduce the problem on Linux by connecting to a host blocked by firewall or unplugging the cable on switch.

The only safe approach to handle TCP timeout is to run the connection code in a different thread and interrupt the thread when it takes too long.

ZZ Coder
  • 74,484
  • 29
  • 137
  • 169
  • "If the value is set to infinity, you will not wait forever." As long as it's not about discussion about the meaning of "infinity", it can for sure happen that you wait very very long. We had a case here, where an `HttpURLConnection.getResponseCode()` was hanging for apprx. a week until we restarted the process. There was obviously no timeout set on the JVM side and as well no timeout on the Linux OS side. – Tom Fink Jul 16 '13 at 13:09
  • The final paragraph is not correct. A connect will timeout after about a minute at most. A separate thread is completely unnecessary. You can certainly have *reads* that run forever if there is no data. However the Javadoc is wrong about the default connect timeout being infinite. It isn't. – user207421 Aug 19 '13 at 23:01
  • 1
    @comeGetSome That's not correct. You can shutdown the socket for input. That will cause the blocked read to encounter end of stream. – user207421 Nov 28 '16 at 02:53
  • @comeGetSome: I had to implement this using a thread that holds a reference to an open HTTP URL connection. When said thread closes the connection, the other thread throws "java.net.SocketException: Socket closed". Thank bug JDK-8075484 for making me do that! – fmcato Nov 28 '16 at 15:08
  • @comeGetSome Surely you can call `Socket.shutdownInput()` without having your hand held? NB These timeouts are enforced by TCP, not the JVM. – user207421 May 08 '17 at 00:23
  • @EJP you' right, it works even on Socket.close(); however, the read/write does not encounter EOF in such a case but throws an IO exception. – comeGetSome May 08 '17 at 08:17