Hey Everyone, hope everyone had a great Christmas and successful boxing day !
Context:
I want to each client to to be able to create send multiple emails. After multiple iterations I have landed on the following designs; furthermore, have settled on Tasks.
Questions:
Just out of curiosity, when would the GenServer be more beneficial than Tasks, based on the design?
The main benefit GenServer provides is the ability to maintain long running state. Apart from that are there any performance benefit that GenServer offers over Tasks?
You have a better control with GenServer, while Task is a process meant to do something, then die.
But if it is just to send an email, You could just spawn a process, then You could ask why a Task over a Process?
One day You might decide to have a better control, a better error handling, or just support back pressure⊠You might send billions for Christmas, and less the rest of the year. In this case I would not choose Task.
@kokolegorille are you confusing Task with a job queue? A task is literally just a process. It doesnât provide better control or back pressure, it provides marginally better error handling because it sets some standard values in the process dictionary, but thatâs about it. It isnât heavier weight than a process.
On the note of a job queue, those are often a good idea with something like email. You get retries, concurrency limits, and so on.
Tasks are most useful for failure separation or asynchronous execution for a piece of code. If your current process does need to do something, which is prone to fail, possibly even because of things outside of your control, but hopefully in the control of your user, then Tasks are a good way to start. Same if you want to quickly execute something concurrently to your current process, where persistance of the job doesnât matter. All a task does is basically inline executed code, but wrapped in another process. Only the process starting the task should be interested in the result or failure of the started task â with the only exception being the optional task supervisor. Personally Iâd even say a task should not be very long running as well, because itâs unlike a job queue not sticking around in case of it being stopped by external factors.
Iâm with @benwilson512 here, that for emails a proper job queue is a better fit, because you can be more certain that the email will indeed be sent. Sending emails are something once the initial webrequest is successful your system is in charge to fulfill.
Tasks imo are more useful for code, where your system is not in charge if there are failures. E.g. take processing an user uploaded file. If the processing fails (and your code works correctly) your system cannot do anything to make it work. The user needs to fix the input from their side.
Iâd like to make this a bit more concrete. A task is meant to be an alternative to using spawn, but be otp conform (see :proc_lib), so it can be properly supervised/shut down. With that itâs less likely to leak processes with tasks. A task therfore is more than âjust a processâ given it implements otpâs messages, but itâs like spawn just meant to execute a piece of code and be done.
A task is meant to be an alternative to using spawn , but be otp conform (see :proc_lib ), so it can be properly supervised/shut down.
Thereâs also some elixir-only goodness in there with the :$callers stuff which makes async unit testing with Ecto, Mox, Hound, Wallaby, etc. effective.
In short, âalmost always use Task over spawnâ.
One limitation I ran into using Task.async_stream, one slow process will stop the processing of future work. Say you have 1000 items and number 30 takes significantly more time than the rest (as is with email commonly), processing at a concurrency of 8 for example the 39th task wonât be executed because it will be waiting on the 30th to complete. This happens because the Task.async_stream function ensures ordering, using a selective receive against the PID.
Therefore, unless the time to process a particular task has a particularly low std dev, it will be more efficient to build your own solution. This all assumes youâve got the load to justify of course, otherwise they may seem the same in a low volume system.
!
