Create server launcher to replace mcserver

[tonygermano]

mcserver was created by install4j, and the configuration was not open source. I don't believe that a replacement for mcservice is required, as each platform has a preferred way to run a service, and they should all work with a simple launcher.

needs:

• a binary or script that can run with a double-click (source code must be open)
• must process a .vmoptions file as described here or something similar in a different documented format.
  • in addition to directly using options as arguments to the java executable, it supports special values for:
    • replacing, appending to, or prepending to the classpath
    • including other vmoptions files, with environment variable substitution in the path
• ensure that the classpath is built in the correct order. Certain project libraries reimplement classes from other libraries and must come earlier on the classpath.
• able to locate a jvm with which to launch the server

nice-to-haves:

• easy (and well documented) way to configure it to launch using a specified jvm. Shouldn't require a system-wide jvm to be installed.
• detect java version and automatically include known required options for java 9+

Platform support (check as completed):

• Windows
• macOS
• Linux (+docker)

[ssrowe]

I think this may be 2 separate issues.

1. Server launcher/Daemon
2. Setup/install

For the daemon, Apache Commons Daemon might be a good choice. It appears widely used, small overhead, with cross-platform capability and native integrations for both Windows and *nix.
https://commons.apache.org/proper/commons-daemon/index.html

For the setup, jpackage appears to be officially supported from OpenJDK 16. While it appears rudimentary, it does have native support for Windows and *nix.
https://openjdk.org/jeps/392

[kpalang]

easy (and well documented) way to configure it to launch using a specified jvm. Shouldn't require a system-wide jvm to be installed

We could look into using the distributions backend used by SDKMAN to choose a JVM.

[tonygermano]

I think this may be 2 separate issues.

1. Server launcher/Daemon
2. Setup/install

I think those are actually 3 issues.

1. Server launcher (wrapper around java binary to run in foreground)
2. Server Daemon (daemonize launcher)
3. Setup/install

I intended for this issue to only cover the first of those 3.

We could look into using the distributions backend used by SDKMAN to choose a JVM.

Personally, I'd prefer good documentation over trying to do too much.

I.e., in the setup guide:

- Do XXXX to specify the location of your preferred java runtime
- If you need help choosing or downloading a java runtime, see <link to other help article>

Down the road if we want to include a separate tool to assist with acquiring a java runtime, I think that's a separate feature request. In the near term, using SDKMAN itself could be one of the suggestions in the help article.

[ssrowe]

@tonygermano can you explain why you'd want/need a wrapper to run in the foreground? and why that should be different than the daemon launcher? i look at the engine as something that should only be ran as a service - os, docker, whatever. and running in the foreground is simply a feature used for troubleshooting.

a binary or script that can run with a double-click (source code must be open)

can you elaborate on this? i assumed this meant an installer.

[tonygermano]

@ssrowe I'm using mirth lingo here as it exists in 4.5.2.

Mirth has always offered two ways to start the server, mcserver and mcservice. mcserver runs in the foreground and logs information to the console. Sometimes it provides additional information than what makes it into mirth.log. mcservice starts a daemonized process and lets you manage it with stop/start/status commands, but in most cases, you still want to rely on an OS level service manager to manage the process instead.

In modern systems, mcserver should be the preferred way to start the server. For development purposes, you likely want to be running in the foreground. Docker prefers that the main process runs in the foreground. This also allows it to capture sysout to make it available when running docker logs. Systemd prefers services that run in the foreground, which allows it to manage starting and stopping processes itself rather than outsourcing that to a different application. Running in the foreground will also let systemd collect logs in a standard way.

I am proposing that for this issue we only recreate mcserver. A separate issue would be creating the OS specific methods for creating a service to run the launcher. Windows is the only OS that really presents any difficulty with that piece.

Docker shouldn't use a daemon process because you typically would not want to launch a background process inside the container that you need to manage. If you want to stop the server, you should just need to stop the container and not need to mess around inside of it. To further that point, the NextGen docker containers run mcserver, not mcservice.

Systemd only requires a .service unit file to create a service on Linux systems. This has already been shown to work with mcserver through multiple forum posts/slack discussions. I'm not as familiar with mac, but the launchd .plist files look very similar to how systemd works.

[ssrowe]

@tonygermano i think we’re saying essentially the same thing. The “double-click” thing threw me off.

i agree we only need a server component that runs in the foreground and that is ran from the CLI interactively or from systemd, docker, or similar. Essentially a bootstrapper.

while Windows is more unique, there appears to be some differences between other platforms as well. with a very simple interface, we can leverage the Apache Commons Daemon (don’t let the name confuse things). It’s simple a set of platform native binaries that give us more control over class loading and config than a shell scripts which diff between platforms. It does have some overlap with systemd, that we can simply ignore.

this appears to be battle-tested code that would allow us to simplify things. Thoughts?

[mgaffigan]

I made a crack parsing vmoptions in bash in #101 which I expect might apply for *nix platforms. I'm of the opinion that any non-trivial server app should be running in a container, these days, but assuming the bash version is acceptable I'm happy to produce a windows equivalent that runs as an NT Service. Systemd, too.

Beyond whether the quick-and-dirty vmoptions support is sufficient, I'd need clarification re:

• Where classpath should come from and what the correct order is, since I did not see it in reimplementation of mirth-connect.sh
• What JVMs are "supported" and differentiated options (seems like mcservice-java9+.vmoptions is no more)

[tonygermano]

I made a crack parsing vmoptions in bash in #101 which I expect might apply for *nix platforms. I'm of the opinion that any non-trivial server app should be running in a container, these days, but assuming the bash version is acceptable I'm happy to produce a windows equivalent that runs as an NT Service. Systemd, too.

Beyond whether the quick-and-dirty vmoptions support is sufficient, I'd need clarification re:

@mgaffigan I have already created a clojure program that does what I intended when I opened this issue, but I do not like how it needs to be deployed and run. See #61

I was thinking about rewriting it in Go as that should not be difficult to do, and it should then more easily compile to platform native executables. My priorities needed to shift elsewhere before I could get around to doing that, and we are using install4j in the near-term to be able to get a release out for people to be able to install and test the application.

An alternative that I considered was rather than having a tool that launched java as a child process, it could just generate and return the full command to start java with the appropriate args after processing the vmoptions files. Then the output could be executed by a shell or used to create a service.

One of the things I really like that I added, and which is not supported by install4j, is the -java-cmd directive which lets you point to a specific JRE in the vmoptions file, so it's very easy to switch between specific java version when the user has multiple versions available, whether they are installed system-wide or not.

The other things I implemented with environment variable substitution, recursive includes, and classpath manipulation are all described here https://www.ej-technologies.com/resources/install4j/help/doc/concepts/vmParameters.html

• Where classpath should come from and what the correct order is, since I did not see it in reimplementation of mirth-connect.sh

The only thing that must be on the classpath at this time is mirth-server-launcher.jar. It brings in a few more requirements via its manifest, and the rest is all loaded dynamically during runtime. However, the user should be able to specify additions to the classpath if necessary (which can be done by special directives in the .vmoptions files.)

• What JVMs are "supported" and differentiated options (seems like mcservice-java9+.vmoptions is no more)

It was moved to /conf/default_modules.vmoptions and is currently included by /oieserver.vmoptions or /oieservice.vmoptions. I'm 90% sure that java 17 will be the minimum "supported" java version, even though we still build with java 8 for right now.