If schedular is stateless, how do I invoke the stop() function at a later time?

[khan-zia]

I am sorry to be asking a rather simple question here, I tried and went through the codebase but I figured I still need some input from your side.

I have a simple use case. I have a node.js CLI app. When I run a certain command, I schedule a few jobs and the node execution that queues and starts the jobs exits of course. Now, I would like to have another CLI command let's say myapp stop that should be able to stop all previously enqueued jobs. As per my understanding, the new node process executing the myapp stop command would have no link whatsoever to anything the toad schedular is doing in memory. Take a look at this snippent.

export const beginScheduledJobs = (): void => {
  // App must be configured.
  if (getConfig('state') !== 'ready') {
    return;
  }

  // Instantiate new schedular.
  const scheduler = new ToadScheduler();

  // Queue some jobs
  scheduler.addSimpleIntervalJob(idleCheckJob);
};

/**
 * Stops all scheduled jobs.
 */
export const stopScheduledJobs = (): void => {
  // What should I do here ?
};

As you can see, the beginScheduledJobs() method would be called by my apps start command, and the stopScheduledJobs is to be called on-demand by the user later by my app's stop command. Any help would be greatly appreciated.

[khan-zia]

@kibertoad The only thing I have in mind, which feels a bit of a hack, is to use an external json file to set a start/stop flag. Although I use a json file for config etc anyway. So what I have in mind is that my stop command would set a stop flag in the json config file, and then each of my running jobs, before doing the actual job would check for the flag and abandon if the flag is set. Something along those lines...

[kibertoad]

@khan-zia Can you explain a bit more what you are trying to achieve? If you want to stop all jobs at once, you can call scheduler.stop(), and this will stop all of the jobs. And if you want to stop some specific jobs, you can store their instances somewhere, or lookup the one you need via scheduler.getAllJobs()

[khan-zia]

@kibertoad my use case is a bit different. I have a node CLI. When I invoke the myapp start command, I schedule some background jobs. But I don't want to keep the terminal occupied or require my user to keep the terminal open so I have to exit the main process that just executed the myapp start command. To achieve this, I spawn a new child process, I run the schedular on the child and then I completely detach the child from the parent allowing the parent process to exit.

Now, the other command I have is myapp stop which allows my users to stop the background jobs. The only problem is, the new node process that executes the stop command, has no idea, no link whatsoever to the now independent process from the previous command, let alone having a reference to the toad schedular's object to call the .stop() method on. So what is your suggestion for such a use case?

PS.
I ended up writing a C program that accurately identifies the process running my jobs and kills it by PID. I invoke the C binary from node whenever a user tries the myapp stop command.

[laser]

@khan-zia

So what is your suggestion for such a use case?

You can achieve this in a MacOS or Linux environment by using one or more named (FIFO) pipes.

Basically, you'd author your Node.js daemon (the one in which you do the toad-scheduler stuff) such that you initialize it with a path to a FIFO pipe. When something writes to the FIFO pipe, you do your shutdown sequence. You could add a second FIFO pipe to which your daemon could write some bytes when shutdown has completed.

Then, you'd author your myapp start program. This thing would be pretty basic; it'd just write something to stop pipe and then read from the completion pipe (if desired).

[khan-zia]

@khan-zia

So what is your suggestion for such a use case?

You can achieve this in a MacOS or Linux environment by using one or more named (FIFO) pipes.

Basically, you'd author your Node.js daemon (the one in which you do the toad-scheduler stuff) such that you initialize it with a path to a FIFO pipe. When something writes to the FIFO pipe, you do your shutdown sequence. You could add a second FIFO pipe to which your daemon could write some bytes when shutdown has completed.

Then, you'd author your myapp start program. This thing would be pretty basic; it'd just write something to stop pipe and then read from the completion pipe (if desired).

I ended up with something even more straightforward that just works regardless of the operating system or anything else. I wrote a small script in C that uniquely identifies the node.js process that's running in the background handling the toad schedular. I simply invoke the C binary by spawning a child process when myapp stop command is executed which in turn simply terminates the other node.js process running the schedular. That works perfectly for what I wanted.

[kibertoad]

The scheduler is in-memory per process, so cross-process control needs an external signal (IPC, named pipe, file flag, signal handler) — same pattern as any in-memory daemon. Closing as a usage question; the workaround you landed on (PID-based stop) is reasonable.