Server lifecycle management

[scholarsmate]

The problem: Sharing a single server

Ωedit can handle multiple editing sessions using a single instance of the server listening on a given interface and port. It may not be appropriate for the process that starts up the server to also be the process that shuts it down because there could be sessions created from other processes that are in progress. Allowing multiple processes to share a single Ωedit server ought to be supported.

Possible solution

When a server is initially started up, it should wait to process its first create session request. Sessions will then be created and destroyed. When the number of sessions being managed by the server drops to zero, the server can be safely shutdown without risk of data loss. Clients can discover the number of sessions using getSessionCount. During shutdown, an application can check the session count and if it's zero, then the server can be taken offline, and if the session count positive it should remain running. There ought to be an RPC call to take the server offline (e.g, shutdownServer) that uses context.system.terminate() instead of having to kill it using some platform-specific mechanism (e.g., kill).

A little node command line utility that can check if a server is online given some interface and port (returning something like unable to connect, or the pid and server version if connected successfully), query the number of sessions, and can shutdown the server via the RPC call will be handy for scripting (#553).

// How to get the process ID of the running application

import java.lang.management.ManagementFactory

val pid = ManagementFactory.getRuntimeMXBean().getName().split("@")(0).toInt
println(s"Application PID is: $pid")

Edge cases

1. The application that created a session is killed without destroying its session.

A possible solution (#552) is to require the application to send a heartbeat (probably every second or two) with a list of sessions that it's managing. If some number of heartbeats are missed (e.g., 5-10 (configurable)), then those sessions that haven't been "heard from" within that time period will be timed out and destroyed.