In the method from Connection, how much timeout should I give it? :S I have no idea what a normal timeout would be, how much time should it take? :)
I dont want isValid() to return false if it could return true if it had gotten more time, but also I don't want it to slow down the whole program and give me "freezes".
If I set 0, does that mean I don't care for any timeout, it will try for as long as it needs to?
Thanks!
This depends on a lot of things. Generally, I'd assume that the time that isValid takes is about the same time that a simple query would take. For that reason, I would use the maximum acceptable time for the user.
E.g. if you think that users of your (say) web application will wait at most 5 seconds for a response before giving up, you might want to use that value for isValid. Because it makes no sense to declare the connection valid if it takes, say, 50 seconds to reach the database.
I have no idea what a normal timeout
would be, how much time should it
take?
Then put the timeout into the program configuration (whatever this is). Maybe log the events when timeout occur and get some experience over time what a normal timeout is.
... but also I don't want it to slow
down the whole program and give me
"freezes"
Is this an interactive program for end-users, then think how much time she will wait without to get nervous. For me 2-3 seconds is still ok, dependingwhat the program is doing for me.
Is this a background server program think about what can happen that the connection get delayed (reconnect network, etc). A background program can wait longer.
Related
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 have a scenario where I have some timing data that I get from a MIDI file. When a MIDI note needs to be played, I need to send a command over UDP. Basically, I have instructions that say "play note A, wait 125ms, play note B, wait 300ms, play note C..." and each time I "play note X" I need to send data over UDP. I have tried using both a TimerTask and a simple thread with a loop that check the system time and calculate how much time has elapsed and decide whether or not to play a note based on that, but both methods seem to have timing issues. The TimerTask doesn't run exactly on the specified interval (which was stated in the documentation) so I get erratic messages. The thread works better, but it still hiccups sometimes which I assume is because other threads are getting priority over it.
Is there a better way to send this data with more accurate timing? Is there something I can use like the Clip interface in Java that is used for playing audio?
Any assistance is very much appreciated.
This is an approach just about doomed to failure. Let me count the issues here:
1)Android is not a real time OS. Neither is Linux (which its built on). Expecting ms level timings to happen exactly correctly is never going to work. Even if the clock is accurate enough to interrupt on a 1ms rate, there's no assurance that Linux will schedule your thread for wakeup.
2)TimerTasks aren't promised to be accurate even to the degree limited by 1.
3)You're then sending it somewhere via UDP? A protocol that has no assurance as to delivery or timing, to a receiver who will then do something with it- and that receiver may have additional timing issues of its own.
Throw out this entire approach and start over would be my advice. Every single step of this says bad idea.
We all know of sleep method available in java threads..
I understand that the precision in timing depends on the precision of hardware clock in the system..
So my question is how accurate is this method or better say what is the error in milliseconds or nanoseconds considering a general pc.
My requirement its to synchronise data transfer using sleep for timing.. The data is to be sent in fixed in intervals (10-20 millis) and if there is a delay of more than 1sec due to successive error in timing it may be bad !
So is it advisable to use the also method?
Sleep is not the thing you want, as in here.
I suggest to read through this.
If you need to synchronize data, I suggest you do this yourself rather than relying on threads to wake up at preset times. i.e. use one thread to simulate when events occur, in the order you expect them to occur.
I'm using a ScheduledExecutorService to provide an update to a database every hour with the scheduleAtFixedRate method. The problem is that it gradually gets later - in long service I've been logging it and it's about a second a day.
I made a small class just to examine this aspect - seems to work fine when nothing is happening on the PC ( running WinXP ) but if things are going on it rapidly gets later. 18:00:00.5 last night was its first log and this morning was 09:00:00.5 then 10:00:05.9, 11:00:26.8, 12:00:45.3, 13:01:07.8...
I can attach the code although my example isn't the smallest.
Anyone else experienced this? Any ideas why this isn't working properly?
I can think of lots of ways around it but I'd really like to know why it doesn't work as advertised!
Thanks, Mike
This is normal AFAIK. With scheduleAtFixedRate, If any execution of this task takes longer than its period, then subsequent executions may start late. That being said, I'd recommend scheduleWithFixedDelay. This will ensure that tasks are carried out at the specified delay interval.
I am trying to perform some computations on a server. For this, the client initially inputs some data which I am capturing through Javascript. Now, I would perhaps make a XMLHttpRequest to a server to send this data. Let's say the computation takes an hour and the client leaves the system or switches off the system.
In practice, I would use perhaps polling from the client side to determine if the result is available. But is there some way I could implement this in the form of a call back, for instance, the next time the client logs in, I would just contact the client side Javascript to pass the result... Any suggestions? I am thinking all this requires some kind of a webserver sitting on the client side but I was wondering if there's a better approach to do this.
Your best bet is to just poll when the user gets to the web page.
What I did in something similar was to gradually change my polling time, so I would start with several seconds, then gradually increase the interval. In your case, just poll after 15 minutes, then increase every 5 minutes when it fails, and if the user closes the browser then you can just start the polling again.
If you want some callback, you could just send an email when it is finished, to let the user know.
Also, while you are doing the processing, try to give some feedback as to how far you have gone, how much longer it may be, anything to show that progress is being made, that the browser isn't locked up. If nothing else, show a time with how long the processing has been going on, to give the user some sense of progress.