How can I specify a timeout on an active java.net.Socket connection? I don't mean the timeout of .accept() that blocks the process. I'd like to set a timeout that starts to count when accept method takes a connection, until the client connection is closed/output stream is returned.
Is that possible?
yes. it is possible with socket.setSoTimeout()
Related
I have two beans creating a client socket connection to a server: AbstractClientConnectionFactory and TcpOutboundGateway.
The server offers a timeout of 1 minute.
Question: which timeouts do I have to set on the beans so that spring/java does not terminate the connection before the timeout of the server?
The following properties are available:
factory.setSoTimeout();
gateway.setRequestTimeout();
gateway.setRemoteTimeout();
Which of those timeouts is the correct one to set from a clients perspective? Or should I just set them all to equal 60000L?
I'm asking because I' just using factory.setSoTimeout(60000L) by now, and getting socket timeouts after 10sec. So maybe I have to additionally set the gateway timeouts?
I also discovered that gateway.setRemoteTimeout(60000L) prevents the timeout only when set. So it's probably correct to also set this value (though I don't understand why timeout has to be configured twice).
Still the question remains what .setRequestTimeout() is for.
factory.setSoTimeout();
The SO timeout is set on the socket itself; if no reply is received within that time, the reader thread gets an exception. If we haven't sent a message recently (meaning we are expecting a reply), the socket is closed. If we did send a message recently we'll wait for one more socket timeout after which the socket is closed.
gateway.setRequestTimeout();
This only applies if the factory singleUse is false (meaning a shared single connection). It is the time we wait to get access to the socket if another request is in process. Since TCP has no natural mechanism for request/reply correlation, we can't have 2 (or more) requests outstanding so the second request has to wait until the first one completes. If singleUse is true a new socket is used for each request so this is not needed. The CachingClientConnectionFactory provides a mechanism to use a pool of shared sockets. Again, this timeout does not apply (but the pool has a timeout if all the sockets are in use).
gateway.setRemoteTimeout();
This is how long the gateway itself will wait for a reply; if this expires, the socket is closed.
SO timeout and remoteTimeout effectively do the same thing; just with different implementations.
You can set both to at least the time you expect a request to take, or leave the SO timeout to default (infinity).
Basically am a newbie to socket programing. i would like to know about how to close a socket if stays idle for a specified time interval. i searched on net about this ,i found that function which is used to close the socket after the specified interval. but here in my case , i would like to close the socket only when it is stays Idle for more than the specified interval
I searched on net about this
Why? The Javadoc exists. No searching necessary.
I found that function which is used to close the socket after the specified interval
There is no such method.
I saw about setSoTimeOut(2000) function which closes the socket after the specifed time interval
No it doesn't. It doesn't close the socket at all, and it causes read methods to throw a SocketTimeoutException if no data arrives within the timeout period.
but I would like to close only if the socket remains idle for the specified interval
Socket.setSoTimeout() is exactly what you need.
the client establishes the connection with the server and then later after sometime it the client close the socket connection at its side after performing the required task and creates a new connection the next time when it pings, where as my server does not close the connection and it keeps on listening to that client
In other words your server is ignoring end of stream on the socket. Don't do that. Close the socket if you get end of stream from a read method.
If I set soTimeout on java sockets what will be the behaviour in case of active peer vs passive peer. For instance if I have a readtimeout value 1 minute and having a file transfer and which takes 5 minutes will it get readtimeout exception or not ? For me its necessary to get timeout exception when connection hangs.
The soTimeout setting explicitly affects operations that read from the socket's input stream. You can think of it as allowing the caller to define a timed block on read operations. From the Javadoc for setSoTimeout:
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.
In the case of a passive peer, no timeout will be thrown solely due to the peer not calling read. However, if and when it does make a read call, the call must return data before the soTimeout expires, or else a SocketTimeoutException will be raised.
I'm having a problem with a library that I am using. It might be the library or it might be me using it wrong!
Basically, when I do this (Timeout in milliseconds)
_ignitedHttp.setConnectionTimeout(1); // v short
_ignitedHttp.setSocketTimeout(60000); // 60 seconds
No timeout exception is generated and it works ok, however, when I do the following,
_ignitedHttp.setConnectionTimeout(60000); // 60 seconds
_ignitedHttp.setSocketTimeout(1); // v short
I get a Socket Exception.
So, my question is why can I not simulate a Connection Exception? Am I misunderstanding the difference between a socket and a connection time-out? The library is here (not officially released yet).
A connection timeout occurs only upon starting the TCP connection. This usually happens if the remote machine does not answer. This means that the server has been shut down, you used the wrong IP/DNS name, wrong port or the network connection to the server is down.
A socket timeout is dedicated to monitor the continuous incoming data flow. If the data flow is interrupted for the specified timeout the connection is regarded as stalled/broken. Of course this only works with connections where data is received all the time.
By setting socket timeout to 1 this would require that every millisecond new data is received (assuming that you read the data block wise and the block is large enough)!
If only the incoming stream stalls for more than a millisecond you are running into a timeout.
A connection timeout is the maximum amount of time that the program is willing to wait to setup a connection to another process. You aren't getting or posting any application data at this point, just establishing the connection, itself.
A socket timeout is the timeout when waiting for individual packets. It's a common misconception that a socket timeout is the timeout to receive the full response. So if you have a socket timeout of 1 second, and a response comprised of 3 IP packets, where each response packet takes 0.9 seconds to arrive, for a total response time of 2.7 seconds, then there will be no timeout.
We are doing FTP connection through our applicaion which is a JAVA aplication.
We have set timeout for connection using Socket.connect(Adreess,timeout) method before calling FTPClient.connect() method.
During retriving files from the FTP site under same connection we havent set any timeout. Is it mandatory to call method FTPClient.setSoTimeOut(timeout) method to set individual time out for each such interaction under same connection or Socket.connect(Adreess,timeout) method will set timeout for each interaction with FTP site under one connection?
I would also like to know What is the difference between these two methods?
The timeout in Socket.connect() is connect timeout, which is the time to wait for TCP handshake to finish. This timeout only occurs once per connection.
setSoTimeout() is called socket read timeout, which is how long you wait to read pending bytes from socket. This occurs on every socket read throughout the TCP session.
It's good practice to set both timeout value so you don't rely on system defaults, which may vary. However, the timeout may not work sometimes when the call is stuck in native code. For example, the connect timeout is not honored if firewall silently drops packet.