15

I trying to make a call to a very heavy duty process. It's average work length is estimated by 9-10 minutes.

When I'm executing the process, I set the timeout for a ridiculously huge number: 99999999.

After 2 minutes, I get the following error:

java.net.SocketTimeoutException: Read timed out

I tried to mess with it some more, and I set the timeout to 3000, and after 3 seconds as anticipated I got the same error.

Do you have any idea on why socket.setSoTimeout(99999999) sets it to 120000 max?

apaderno
  • 28,547
  • 16
  • 75
  • 90
Urbanleg
  • 6,252
  • 16
  • 76
  • 139
  • 3
    This method passes to the OS so the behaviour of this method depends on your OS. Which version of the OS are you using? – Peter Lawrey Sep 13 '12 at 12:53
  • 1
    Have you tried sending keep-alive messages or have the process "call" you back when it's completed instead of keeping a socket open for ages? – Vala Sep 13 '12 at 12:53
  • 1
    It seems the OS just rejects your value because if it is out of range. I would try playing with higher values but not so high (you are setting it to more than 27 hours). v.g., 3 minutes, 5 minutes, 10 minutes. – SJuan76 Sep 13 '12 at 13:01
  • 1
    If you don't want a time-out, I would try not setting it rather than setting it very high. – Peter Lawrey Sep 13 '12 at 13:02
  • I set it to 3 minutes, still after 2 minutes i get an exception – Urbanleg Sep 13 '12 at 13:45
  • Could you please paste your code setting the timeout and opening the socket? – fglez Oct 03 '12 at 14:21

3 Answers3

4

I had the same problem and the solution was not use socket.shutdownInput(); socket.shutDownOutput(); until the last time of reading or writing data to the socket. This made the socket go to FIN_WAIT state thus waiting 2 minutes before closing. You can read more about it in this post

Community
  • 1
  • 1
Rotem
  • 2,306
  • 3
  • 26
  • 44
  • This technique cannot possibly solve a read timeout exception. – user207421 Jun 11 '13 at 10:24
  • If you took the time to run my test case you would have seen that this is the solution. and you can try it your self, write some inputs to a socket and use `shutdownInput` and you will see that the socket will change to FIN_WAIT state. wait 2 minutes and you will see that the socket is closed. – Rotem Jun 11 '13 at 10:35
  • Shutting down a socket has no effect on read timeouts. Shutting down the other end might, but so would sending something. This does not address the question: "why socket.setSoTimeout(99999999) sets it to 120000 max?" – user207421 Jun 12 '13 at 08:50
  • The "socket.setSoTimeout(99999999) sets it to 120000 max" is just a side effect. Let say you created a socket and connected to the other end, you can see with netstat -na| find "portnumber" that the socket is in ESTABLISHED state. Now send some input and use `shutdownInput` you will see that the socket state turn to CLOSE_WAIT. Again, if you would have run my test case in my post you could have seen this yourself. – Rotem Jun 12 '13 at 10:58
  • 1
    The "socket.setSoTimeout(99999999) sets it to 120000 max" is the *problem.* Shutting down the socket does indeed change the port state, and send a FIN, and cause an EOS condition at the reader, but it doesn't change the read timeout. You don't have to run test cases to know that. – user207421 Jun 12 '13 at 11:07
2

Clearly you aren't setting the timeout you think you're setting, or someone else is changing it afterwards. You'll have to post some code to get further elucidation.

Note that according to W.R. Stevens in TCP/IP Illustrated, Vol II, #17.4, the timeout is held in a short as a number of 1000Hz ticks, so a timeout beyond 11 minutes isn't possible. This applies to the BSD code.

user207421
  • 305,947
  • 44
  • 307
  • 483
1

I'm not sure how your application works, but try to set an infinite timeout to the socket

public void setSoTimeout(int timeout)
              throws SocketException

Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

If you provide more information about your call, i may improve the answer.

Community
  • 1
  • 1
F. Mayoral
  • 175
  • 1
  • 10
  • I tried setting the time out to 0. (which supposed to be infinite time) but again, after 120 seconds it throws an exception. – Urbanleg Sep 13 '12 at 13:44
  • While you are connected, does the buffer reads any data at all? i mean, is the server responding to your connection?, because there is a chance that the server address is not resolved correctly in your network, i don't know if it's local, or a vpn, or just a remote server, i don't know if the adress is resolved using a netbios query, or the host file, or a remote dns, there are lots of elements that can lead to the wrong address – F. Mayoral Sep 13 '12 at 14:01
  • the server is local, when i'm setting the heavy duty process to take less than 2 minutes it works just fine. – Urbanleg Sep 13 '12 at 14:06
  • Is there any application container that might be overwriting your connection timeout with the default timeout, like Websphere, apache tomcat or jboss in the server or the client side? if so, you should check the enviroment's configuration – F. Mayoral Sep 13 '12 at 14:16
  • fer13488, nope no containers whatsoever. – Urbanleg Sep 13 '12 at 14:31
  • So you have two standalone apps, a server and a client, i'm pretty sure it must be a configuration issue, but being custom listeners and connectors I don't know where you should look, do you have any configuration file for your applications?, server.xml or something like that? you should check the connectionTimeout value, it must be some global setting, i can't think of anything else since i don't really know the execution enviroment =/ – F. Mayoral Sep 13 '12 at 14:51