sandorbedo

sandorbedo

Hi,

I use Task.async_stream to execute tasks on an extremely long stream of elements. Basically I use it as a pmap, except that I don’t care about the results, just the side effects of the tasks.

My question is: can I spawn those tasks in the cluster, utilizing all the available nodes? Can Task.Supervisor.async_stream somehow start tasks under more than one supervisors (started one supervisor on all the nodes) in a round robin fashion or select a node by a given hash function?

Showing Posts 1 to 5

benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Do you care that the side effects succeed? If you want retries and so on you probably want something like Oban.

sandorbedo

sandorbedo OP

Yes, I’d like to know if every Task terminated :normally.

Oban uses PostgreSQL. That is not an available option in my case.


Actually, I came up with a solution that is not yet perfect, but I believe this is the right direction. Imagine a cluster where all nodes have a local Task.Supervisor with a locally registered name :task_supervisor_local_name, and also a gen server like this one:

defmodule SupDispatcher do
  use GenServer

  @retry_count 3

  def start_link(_ \\ nil), do: GenServer.start_link(__MODULE__, [], name: __MODULE__)
  def init(_), do: {:ok, @retry_count}

  def handle_call(
        msg = {:start_task, [_task_owner, _callers, _monitor, {_m, _f, a}], _restart, _shutdown},
        from,
        retry_count
      ) do

    nodes = Node.list([:visible, :this])
    index = :erlang.phash2(a, length(nodes))
    drawn_node = Enum.at(nodes, index)

    try do
      GenServer.call({:task_supervisor_local_name, drawn_node}, msg)
    catch
      _, _ when retry_count > 0 ->
        handle_call(msg, from, retry_count - 1)

      x, y ->
        {:reply, {:error, {:exception, x, y}}, @retry_count}
    else
      {:ok, pid} ->
        {:reply, {:ok, pid}, @retry_count}

      _ when retry_count > 0 ->
        handle_call(msg, from, retry_count - 1)

      error ->
        {:reply, error, @retry_count}
    end
  end
end

The intented usage of this is that when I call Task.Supervisor.async_stream_nolink on any node, I actually use the above GenServer instead of a Task.Supervisor. The gen server accepts the :start_task message, and chooses a node (based on the arguments of the given call) with phash2. Then it simply forwards the request to the Task.Supervisor on the selected node. The remote Task.Supervisor starts the task, returns the pid of the task to the GenServer, and then the GenServer returns the same pid to the async_stream_nolink as if it was a supervisor. This seems to work fine. The load is distributed across the non-hidden nodes, and it can even handle nodes coming and going. Except that I do not know if the spawned task was finished. It only knows that the task was successfully started.

Is there any other problem with this approach?

Is it possible to fix this and restart failed tasks?

sandorbedo

sandorbedo OP

Thanks, that’s nice, but the problem I’m trying to solve is somewhat different than that.

My problem: there’s a huge stream of items (millions of things) that has to be processed, one by one. I want to use something like Task.async_stream with option :max_concurrency set to someting reasonable, that spawns tasks for all elements of the stream but also limits concurrency. This is a well known pattern called pmap. The only problem with this approach is that all tasks run on the same node. So, switching to Task.Supervisor.async_stream instead of Task.async_stream is a bit better, since it has a single supervisor argument. (Now I can start those tasks on any node if there’s a Task.Supervisor on it.) It starts all tasks under that (possibly remote) supervisor. This is better, but still not spawning the processes across the whole cluster. Then comes the above GenServer into the picture. It is basically a fake supervisor. Task.Supervisor.async_stream can talk to this fake supervisor and ask it to start tasks. The fake supervisor then spawns tasks under real Task.Supervisor-s on different nodes, and reports back the pid to async_sream just like a normal supervisor would do.

One little problem with this is that when a task is started, but fails for some reason, there’s no way to know about the failure. All I can guarantee is that the task was successfully started, but who knows if it finished normally or not. Maybe using :transient restart strategy would help in some cases, but it will definitely not help when a whole node goes down with unfinished tasks on it.

Maybe there are some other drawbacks of this solution I am not aware of. I don’t know.

I wanted to ask the community if this is the right direction? Is it possible to ask async_stream to restart failing tasks somehow? Maybe my fake supervisor should keep track of the tasks by monitoring them, and when one fails, it should restart it on another node? Maybe I should use GenFlow instead of this hackie solution?

LostKobrakai

LostKobrakai

Do you need cross node orchestration or could all just pull from the same queue? Because for the latter I’d go for a central queue (e.g. sqs) and then run broadway on all your nodes. Broadway does handle error detection/reporting.

— All posts loaded —

Where Next? Top

Trending in Questions Top

katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
apz
I’m new to elixir and just tried to install the elixirLS extension for VScode(ium) and it is throwing some errors that I would like help ...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews