The startserv script is a streamlined command-line tool in GlassFish designed to simplify how the server is started in the foreground. The script accepts the same arguments as the asadmin start-domain command. It starts a single JVM, unlike the asadmin start-domain -v command, which does the same but starts 2 JVMs, the main one in the background and another one that remains in the foreground as a proxy. The optimized startserv script is used by the official GlassFish Docker image. This makes running GlassFish in Docker much easier and more resource-efficient, as it consumes less memory by starting a single Java process instead of two.
In this article, we’ll dive into the details of how the startserv script works, its benefits, and how it compares to other GlassFish start and stop methods.
Start GlassFish with the “startserv” script
The startserv script is located in the bin directory in the GlassFish Server installation.
Using the startserv script is very simple. Just run it without any arguments to start GlassFish in foreground:
bin/startservIt accepts the same arguments as the asadmin start-domain script. So, for example, we can use it to start use a custom myDomain configuration:
bin/startserv myDomainTo start GlassFish in debug mode:
bin/startserv -dThat’s it. This will start GlassFish in foreground, printing all the log messages to the standard output. It reacts on Ctrl+C keyboard instruction to stop the process cleanly – GlassFish will handle the signal, initiate a shutdown and will stop the server in a clean way soon after.
Now, let’s compare this to other ways of starting and stopping GlassFish, and clarify how the startserv script works. Or, more exactly, how it has been optimized recently.
Starting GlassFish in the Background
When you want to start GlassFish in the background, the common command used is:
bin/asadmin start-domainThis command works in the following manner:
- It initiates the AsAdmin CLI tool, which reads the JVM options to start GlassFish from the
domain.xmlconfiguration file. - This process, in turn, starts a new JVM process in the background that uses the options specified.
- Once the second JVM process (which is the main GlassFish process) is up and running, the AsAdmin process terminates, leaving GlassFish running independently in the background.
This approach provides a clean way to start GlassFish in a background process, allowing the user to continue working in the same terminal or shell. After the command completes, it’s guaranteed that GlassFish server is running and can respond to further commands or requests.
Stopping GlassFish
When it’s time to stop GlassFish, there are multiple equivalent commands you can use. Depending on your GlassFish version and installation setup, you can stop the server with any of the following commands:
bin/asadmin stop-domain
glassfish/bin/asadmin stop-domain
glassfish/bin/stopserv
bin/stopserv # Available since GlassFish 7.0.6These commands function identically and accept the same arguments, such as the domain name. The stopserv script, starting with GlassFish 7.0.6, has been copied to the bin directory for easier access.
Starting GlassFish in the Foreground
Running GlassFish in the foreground is particularly useful in a Docker container or when running GlassFish for debugging or monitoring purposes.
As described above, since GlassFish 7.0.6, you can start GlassFish in foreground simply with:
bin/startservTo stop it, just press Ctrl+C.
Before GlassFish 7.0.6, if you wanted to start GlassFish in the foreground (so that you can see its output in real-time), several commands would get the job done:
bin/asadmin start-domain -v
bin/asadmin start-domain --verbose
glassfish/bin/asadmin start-domain -v
glassfish/bin/asadmin start-domain --verbose
glassfish/bin/startservNotice that even before GlassFish 7.0.6, there was a startserv script. However, this script simply delegated to bin/asadmin start-domain --verbose.
These commands not only start GlassFish but also ensure that output from the server is printed directly to the terminal. Let’s take a closer look at what happens behind the scenes (it’s very similar to the steps for running GlassFish in the background):
- AsAdmin JVM Process: The first step involves the AsAdmin Java process reading the JVM options from the
domain.xmlfile. - Main JVM Process: A new JVM process is then started in the background, and this is where the main GlassFish process runs.
- Terminal Output: The twist here is that the standard output of the second JVM process (the main GlassFish process) cannot be directly displayed in the terminal. Instead, the first AsAdmin process reads the output of the main process and prints it to the terminal.
- Perception of a Single Process: From the user’s perspective, it looks like a single GlassFish process is running and producing output in the terminal. In reality, two JVM processes are running simultaneously, with one relaying the output of the other and also reacting to the Ctrl+C keyboard shortcut and delegating the signal.
The optimized “startserv” Script
The new startserv script still starts 2 JVM processes, but stops the first one before the second one is executed. That remains a single main Java process running. Let’s take a closer look at what happens:
- AsAdmin JVM Process: The first step involves the AsAdmin Java process reading the JVM options from the
domain.xmlfile. The difference here is that thestartservscript instructs it to output the command line to start the Main JVM process instead of launching it. - Main JVM Process: A new JVM process is then started using the command line provided by the AsAdmin JVM Process, and this is where the main GlassFish process runs. This command runs directly in the foreground. The
startservscript leaves all interactions with input and output to this JVM process. - A Single Process running: From the user’s perspective, nothing changes. However, now we really get a single JVM running. In fact, even the original startserv script is stopped and everything works in the same way as if you executed the plain
javacommand on command line.
The “startserv” Script in Docker
In the context of Docker, the “startserv” script is a major advantage. The official GlassFish Docker container now uses this script by default, which simplifies the process of launching GlassFish in containers. Unlike older methods that required two Java processes, “startserv” reduces memory consumption by running only a single JVM. This makes it much more efficient for cloud and containerized environments, where memory and resource management are critical.
Conclusion
The “startserv” script and the other associated commands in GlassFish offer flexibility in how you manage server processes across different platforms. Whether you are starting GlassFish in the background for production use or running it in the foreground for debugging and monitoring, the available commands provide comprehensive control over the server’s lifecycle. Its adoption in Docker containers further streamlines operations, making GlassFish easier to manage in resource-constrained environments.
