I have made connection to the wechat api using HttpUrlConnection and set connectTimeOut to 500 milis and got the response in 3 seconds and now I decreased the connectTimeOut to 100 milis and getting the response in 2 seconds. So not able to understand the reason behind this, see the code and javadoc but not found anything related to it.
You are confused. Connection timeout is not the maximum time to read the response, it is the maximum time to create the connection. Sending the request and reading the response come afterwards.
If you got a response, clearly the connection succeeded within your timeout period, but it then took some seconds to read the response. These are not the same thing.
Possibly you may want to set a read timeout as well, or instead.
But the timeouts you're setting are ridiculously short. Three seconds for a connect timeout and ten seconds for a read timeout would be about the minimum.
Related
I have been trying to understand the difference between apicallattempttimeout and apicalltimeout. What I could understand is apicalltimeout is the total time till the client request waits for the response before giving up whereas apicallattemptimeout includes timeout for retries as well in addition to the time in the first attempt.
So does this mean that apicallattemptimeout will always be more than apicalltimeout? Example : Suppose I keep apicalltimeout to be 1000ms and for a single retry I want the timeout to be 300ms. So values will be for apicalltimeout= 1000ms and apicallattemptimeout= 1300ms ? API docs dont seem to help here
apicallattempttimeout and apicalltimeout
I have this simple Spring boot based web app that downloads data from several APIs. Some of them don't respond in time, since my connectionTimeout is set to somewhat 4 seconds.
As soon as I get rid of connectionTimeout setting, I'm getting an exceptions after 20 or so seconds.
So, my question is, for how long am I able to try to connect to an API and what does it depend on? Where do those 20 seconds come from? What if an API responds after 40 minutes of time and I won't be able to catch that specific moment and just gonna lose data. I don't want that to happen. What are my options?
Here's the code to set the connection. Nothing special.
HttpComponentsClientHttpRequestFactory clientHttpRequestFactory = new HttpComponentsClientHttpRequestFactory(HttpClientBuilder.create().build());
clientHttpRequestFactory.setConnectTimeout(4000);
RestTemplate restTemplate = new RestTemplate(clientHttpRequestFactory);
Then I retrieve the values via:
myObject.setJsonString(restTemplate.getForObject(url, String.class));
Try increasing your timeout. 4 seconds is too little.
It will need to connect, formulate data and return. So 4 seconds is just for connecting, by the time it attempts to return anything, your application has already disconnected.
Set it to 20 seconds to test it. You can set it to much longer to give the API enough time to complete. This does not mean you app will use up all of the connection timeout time. It will finish as soon as a result is returned. Also API's are not designed to take long. They will perform the task and return the result as fast as possible
Connection timeout means that your program couldn't connect to the server at all within the time specified.
The timeout can be configured, as, like you say, some systems may take a longer time to connect to, and if this is known in advance, it can be allowed for. Otherwise the timeout serves as a guard to prevent the application from waiting forever, which in most cases doesn't really give a good user experience.
A separate timeout can normally be configured for reading data (socket timeout). They are not inclusive of each other.
To solve your problem:
Check that the server is running and accepting incoming connections.
You might want to use curl or depending on what it is simply your browser to try and connect.
If one tool can connect, but the other can't, check your firewall settings and ensure that outgoing connections from your Java program are permitted. The easiest way to test whether this is a problem is to disable anti virus and firewall tools temporarily. If this allows the connection, you'll either need to leave the FW off, or better add a corresponding exception.
Leave the timeout on a higher setting (or try setting it to 0, which is interpreted as infinite) while testing. Once you have it working, you can consider tweaking it to reflect your server spec and usability requirements.
Edit:
I realised that this doesn't necessarily help, as you did ultimately connect. I'll leave the above standing as general info.
for how long am I able to try to connect to an API and what does it depend on?
Most likely the server that the API is hosted on. If it is overloaded, response time may lengthen.
Where do those 20 seconds come from?
Again this depends on the API server. It might be random, or it may be processing each request for a fixed period of time before finding itself in an error state. In this case that might take 20 seconds each time.
What if an API responds after 40 minutes of time and I won't be able to catch that specific moment and just gonna lose data. I don't want that to happen. What are my options?
Use a more reliable API, possibly paying for a service guarantee.
Tweak your connection and socket timeouts to allow for the capabilities of the server side, if known in advance.
If the response is really 40 minutes, it is a really poor service, but moving on with that assumption - if the dataset is that large, explore whether the API offers a streaming callback, whereby you pass in an OutputStream into the API's library methods, to which it will (asynchronously) write the response when it is ready.
Keep in mind that connection and socket timeout are separate things. Once you have connected, the connection timeout becomes irrelevant (socket is established). As long as you begin to receive and continue to receive data (packet to packet) within the socket timeout, the socket timeout won't be triggered either.
Use infinite timeouts (set to 0), but this could lead to poor usability within your applications, as well as resource leaks if a server is in fact offline and will never respond. In that case you will be left with dangling connections.
The default and maximum has nothing to do with the the server. It depends on the client platform, but it is around a minute. You can decrease it, but not increase it. Four seconds is far too short. It should be measured in tens of seconds in most circumstances.
And absent or longer connection timeouts do not cause server errors of any kind. You are barking up the wrong tree here.
I'm not sure why this is happening and I've already searched the internet why this is happening but I can't find the answer I'm looking for.
Basically this happens when I try to send a request when the Wi-Fi is off and the mobile data is ON but there is no data. It takes 2 minutes for the exception to be thrown. I wanna know the proper reason why. The timeouts are these:
urlconn.setConnectTimeout(60000);
urlconn.setReadTimeout(60000);
Does this mean that both timeouts occur that's why it took 2 minutes or are there other reason that I'm not aware of why this is happening?
Note: I can only post a code snippet due to confidentiality reasons.
Both of them are occurring. There's no data, so the connection fails, that's one minute. Then there's nothing to read from a stream that doesn't exist due to no connection, that's another minute.
According to the java docs of connection.setReadTimeout() -
"A non-zero value specifies the timeout when reading from Input stream when a connection is established to a resource. If the timeout expires before there is data available for read, a java.net.SocketTimeoutException is raised. A timeout of zero is interpreted as an infinite timeout."
So if I set a certain read timeout, and start downloading a file, will the download break if the timeout is reached?
Or does it break only when there is nothing to read for that specified timeout?
It's only raise exception if there is no response. It'll not break while getting data so don't worry about.
If you start downloading the file and there is no interruption, the timeout will not occur.
If you have the timeout set to 30 seconds. If you're downloading for 15 seconds and after those 15 seconds, the connection fails, you will have to wait another 30 seconds before timeout.
The read timeout starts afresh every time the recv() function is called.
So the correct answer is (2).
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?
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
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.
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.