The start command conveniently launches a cluster (server + workers), but it makes it a bit cumbersome to stop the cluster.
For a short term, hacky solution, a simple killall on Linux could solve it, or the start command could run the server in-process, so that it would block while the server lives.
But in general I think that the server should have a more general and graceful option to stop itself, defined in its API.
Proposal:
The stop event would stop all the connected workers and then shutdown the server.
The command could look like this:
rain stop server:1234
It would probably make sense to stop individual workers too, possibly with the same command and a --worker flag.
The ability for clients to shutdown the server is a non-issue from a security standpoint, since there is already no client authentication and the cluster supposes that it's run in a trusted environment.
There could also be an option for a "soft stop", that would cause the server to stop scheduling tasks, but it would first wait for the current in-progress tasks to finish (and maybe checkpoint them to disk) before stopping the cluster.
The
startcommand conveniently launches a cluster (server + workers), but it makes it a bit cumbersome to stop the cluster.For a short term, hacky solution, a simple
killallon Linux could solve it, or the start command could run the server in-process, so that it would block while the server lives.But in general I think that the server should have a more general and graceful option to stop itself, defined in its API.
Proposal:
The stop event would stop all the connected workers and then shutdown the server.
The command could look like this:
rain stop server:1234It would probably make sense to stop individual workers too, possibly with the same command and a
--workerflag.The ability for clients to shutdown the server is a non-issue from a security standpoint, since there is already no client authentication and the cluster supposes that it's run in a trusted environment.
There could also be an option for a "soft stop", that would cause the server to stop scheduling tasks, but it would first wait for the current in-progress tasks to finish (and maybe checkpoint them to disk) before stopping the cluster.