-
And I don’t want it to take however long it takes because a remote server might go down and what-not. And a task will then have to wait for it forever?
-
Iterations are required because I’m polling a server.
kaa.python
0
peerreynders
- When you start a task schedule a timeout with
Process.send_after/2including thetask.pidin the message - Store the timer reference together with the task in a tuple in the Map
- When the task completes use
Process.cancel_timer/1to cancel the timer. - When the timer message arrives first use
Task.shutdown task, :brutal_killto terminate the task.
1
kaa.python
NobbZ
To make sure you do understand this correctly!
When you send an HTTP-request in the Task and have a timeout of 5 seconds in Task.await but the request takes 10 seconds to process, the request will be done until its very end. AND it will send it answer to its owner anyway. They will be in your inbox and waiting to be processed, regardless of you still want them. Also all sideeffects on the HTTP-endpoint will happen, If you really need a timout over HTTP-requests, use a HTTP library which provides you necessary control over the connection. This will also make sure that the timeout will only start AFTER the request has actuelly been send and not before even starting to construct it. Only milliseconds, but those can become significant!
0
peerreynders
- To point it out again,
Task.awaitactually states:
Compatibility with OTP behaviours
It is not recommended toawaita long-running task inside an OTP behaviour such asGenServer. Instead, you should match on the message coming from a task inside yourGenServer.handle_info/2callback.
- The only thing that times out is the
awaitprocess - the task process it still running.
If the timeout is exceeded,
awaitwill exit; however, the task will continue to run.
1
kaa.python
Ok. How can I do this:
Send an http request.
- a) if an answer arrives within N seconds – good, process it.
- b) if not, forget about it completely – not a big deal because I’ll send another one in M seconds. How can I process or reject a message or all messages if it/they arrives after the timeout?
Note that I need to return something from “do_work” for GenServer so that I can modify its state/data: in my case – either the same state or a state with N - M elements or .
0
kaa.python
Got it.
Should I use spawn?
What message should I handle inside GenServer.handle_info/2 for an answer coming from an http request? Which can arrive after a timeout as well.
0
NobbZ
Your HTTP library should be aware of a timeout option, use it. How your application can then differentiate between a timeout and a regular return value does totally depend on the library you use.
What you can return on a timeout does totally depend on your application.
The important bits are…
- … to drop Task, because it involves coding a lot of stuff into your GenServer which doesn’t belong there
- … to do not do the request in the GenServers process to not block it. How that can roughly look like has been shown to you
0
kaa.python
-
In general, if my library doesn’t deal with timeout and or if timeout occurs in Task.await, how can I process in handle_info? How can I know that :exit has come from one of Task.await because of timeout? How can I flush all messages that’ll arive to the mailbox of GenServer after timeout from Task.await that have timed out?
-
what do you mean by drop Task?
-
HttpPoison does have timeout, but it’s described briefly and still I’ll need to be able to handle a timeout from Task.await.
0
NobbZ
- […]
Obselete after reading my next answer.
- what do you mean by drop Task?
Exactly this. Drop it, throw it away, do not use it, forget it exists.
Using Tasks timout in any way in your current constellation will cause you a lot of trouble. Just use bare processes as shown and explained before.
- HttpPoison does have timeout, but it’s described briefly and still I’ll need to be able to handle a timeout from Task.await.
If you were dropping the idea of using a Task as I told you many times before, there were no need to talk about Tasks timeout here.
HTTPoison will probably return a simple {:error, :timeout} or similar, just try it.
You can “flush” your processes inbox by simply receiving the messages and doing nothing on them, but you should be very careful when doing this to not drop important messages. In a genserver you can do similar in handle_info.
As a last note of warning. Not using HTTPoisons timeout but rather trying to build something around Tasks may get you into huge trouble by either polluting your processes inbox by irrelevant messages which do cost processing just to drop them. This is time where your GenServer is not available for more urgent requests!
Also if you do the cancellation of Tasks wrong it may happen, that HTTPoison is not able to check its worker process back to the connection pool, meaning that you will eventually run out of available connections earlier or later depending on how often a timeout happens.
Also HTTPosisons notion of a timeout is different than Tasks. Tasks timout will start after spanwing the tasks worker process, while HTTPoisons timeout will only start after the request has been prepared and it is trying to establish the connection. As I already said, there are probably only milliseconds of difference, but those may be significant.
1