Skip to content

Conversation

rosa
Copy link
Member

@rosa rosa commented Jul 29, 2024

This PR builds on @bensheldon's initial spike in #115, to run workers and dispatchers in the same process as the supervisor instead of running them as forks. It also considerably refactors the way the supervisor works and it's started, to make room for this.

For now, running in this new async mode is only supported via the Puma plugin but I plan to allow it also when running Solid Queue's supervisor alone in the near future, as a separate PR.

This PR also introduces a breaking change in how Solid Queue is started. Prior this change, you could choose whether you wanted to run workers, dispatchers or both, by starting Solid Queue as solid_queue:work or solid_queue:dispatch. With this PR, the only option available is solid_queue:start. Whether the supervisor starts workers, dispatchers or both will depend on your configuration. For example, if you don't configure any dispatchers, only workers will be started. That is, with this configuration:

production:
  workers:
    - queues: [ real_time, background ]
      threads: 5
      polling_interval: 0.1
      processes: 3

the supervisor will run 3 workers, each one with 5 threads, and no supervisors.

rosa and others added 30 commits July 25, 2024 17:01
That is, no more "work" or "dispatch". The behaviour is the same as "all",
and to get work only or dispatch only it is enough with passing an empty
array for dispatchers and workers.
And make Poller a class that the dispatcher and worker inherit from. It
doesn't make sense to have a module there.
Modes will refer only to forked, async or inline.
Stub fork mode for now.
As these won't necessarily be forks when introducing the async mode.
And affecting the result of `ReadyExecution.count`.
Also, rename SupervisorTest to ForkSupervisorTest, as that's the one
being tested there.
No need to raise exceptions and rescue them, we can just check if a stop
has been requested and terminate accordingly.
Set level to debug for successful enqueue + skipping, and error for
errors, instead of info for everything.
Still not sold on that name, but Single is quite bad.
For worker and dispatcher, on errors outside their thread pool/tasks.
That won't run a loop for supervise, it'll just start the processes and
the maintenance task.
… shutdown

And add an observer for the Supervisor's maintenance task and the
heartbeat task as well.
This is the first approach. Still needs refining.
…r supervisor

They don't claim executions, so no need to include that in the event.
That is, if there is some configuration not empty, do not fill missing
dispatcher or worker with the default. Just assume no
working/dispatching.
`solid-queue-fork-supervisor` vs. `solid-queue-forksupervisor`.
@rosa
Copy link
Member Author

rosa commented Jul 31, 2024

We're now running this branch on HEY to ensure it still works well in the regular forked mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant