Skip to content

WIP: cluster: make scheduler configurable

Rodrigo Muino Tomonari requested to merge github/fork/cjihrig/scheduler-new into master

This is a WIP for making the cluster scheduler configurable by users. This still needs docs, tests, etc.

In the current implementation, the cluster module exports a Scheduler class. The class provides the following methods/hooks:

  • constructor() - Used to configure data structures for managing connections (handles) and cluster workers.
  • addConnection() - Called when a new connection is received. This is where the user would store the incoming connection handle to be distributed later.
  • addWorker() - Called when a new cluster worker is added. This is where the user would add the worker into the pool of workers.
  • removeWorker() - Called when a cluster worker is being removed from the pool.
  • shutdown() - Called when the scheduler is finished working. This would be used to clean up any lingering resources such as handles.
  • schedule() - This is the scheduling algorithm. The output of the algorithm should be a connection handle to distribute, and the worker to distribute it to.

I tried to minimize the exposure of the cluster's inner workings to incoming connection handles. Worker objects are already part of the public API.

Remaining questions:

  • Should we enforce that handles from incoming connections are stored in a queue (array)? This would eliminate the need for the current addConnection() hook.
  • Should we enforce that workers are stored in a "worker id to worker object" map, like they currently are? This would eliminate the need for the addWorker() and removeWorker() hooks.
  • If we can get rid of the connections and workers hooks, then the shutdown hook can probably go. Then we could drop the Scheduler class, and just provide a schedule() function that takes the available workers and handles as input, and schedules accordingly. Ideally, I'd like to go this simpler route, but want to check with some people who are actually doing this in practice to make sure it would be flexible enough. cc: @Yemanu and @redonkulus from #10880 (closed). Would this approach work for your needs?

Closes #10880 (closed)

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

cluster

Merge request reports