The Servoy Application Server comes bundles with an Java Service Wrapper component, to facilitate the automatic launch of the Servoy Application Server when the server on which the Servoy Application Server is installed is started or rebooted.
The Java Service Wrapper does not start the required databases as the databases are not part of the Servoy Application Server, could be running on a completely different machine and different brands of databases have different mechanisms to starting. For more information on running the bundled PostgreSQL as a service, see the PostgreSQL Primer tutorial.
When running the Servoy Application Server and the database on the same Windows machine, both as a Windows Service, then a dependency can be configured between the different Windows services. See Configuring Windows Service dependencies for more info.
The Java Service Wrapper used by Servoy supports virtually all platforms on which a Java Virtual Machine is available (also required to run the Servoy Application Server).
The Java service Wrapper component will create a Windows Service on the Windows platform and on other platforms it utilized Unix Daemons.
The Java Service Wrapper is by default installed by the Servoy All-In-One installer when installing a Servoy Application Server (see Running the All-In-One Installer for more info on the All-In-One installer).
During installation, an extra service directory is created in the ../application_server/ directory. This directory contains, among others, the configuration file for the service, called wrapper.conf.
If the "Setup Service" option is checked in the installer, the Service will actually be setup on the machine. By default this option is unchecked, as in most cases the service configuration will require changes.
The Service component installation comes with two files to install and uninstall the Service: install_service.[bat/sh] and uninstall_service.[bat/sh].
The configuration of the Java Service Wrapper is done through the file wrapper.conf located in ../application_server/service.
When changing the value of any any wrapper.ntservice.* property on Windows, the Service needs to be uninstalled first and reinstalled after the changes have been made.
By default the Windows Service is configured to be started manually. This can be changed by setting the wrapper.ntservice.starttype property to AUTO_START.
The Java Service Wrapper does NOT start the database, as in production environments the database could be installed on a different machine or is maintained by a DBA.
If the database is running on the same machine as a Windows Service as well, it is possible to configure a dependency to it in the Java Service Wrapper configuration. The dependency can be set by adding the name of the Windows Service for the database on which the Servoy Application Service depends as a the wrapper.ntservice.dependency.x property. The "x" at the end of the property name needs to be a sequential number, starting with 1, for each dependency.
When the Servoy Application server is started as a service through the Java Service Wrapper, the assignment of memory goes through the configuration of the wrapper in wrapper.conf, instead of through servoy_server[bat/sh].
Below the mapping for the three relevant memory settings and their equivalent in the wrapper.conf:
For more information on the the meaning of these settings and their suggested values, see Memory Management.
When running multiple Servoy Application Servers as a Service on a single machine, some configuration adjustments are required to not let the different services influence eachother.
The following property requires a unique value:
On Windows the wrapper.ntservice.displayname and wrapper.ntservice.description could be modified to further distinguish the different Windows Services from each other. Note that these two settings are just for display purposes in the Services overview in Windows and do not affect the actual operation of the services.
On OSX and *nix, the name used for the deamon is configured in ServoyServer:
The APP_NAME has to be unique for each Service.
The wrapper.port value does not have to be unique, because the Java Service Wrapper automatically looks for a free port if the specified port is already taken.
The Java Service Wrapper has extensive configuration options. The most fundamental settings have been discussed in this chapter already. In this paragraph some more advanced settings are detailed.
Perform custom action on OutOfMemory exceptions
Java process need to be explicitly told how much memory they are allowed to use. In case the process requires more memory than it's allowed to use based on the configuration, Java will throw OutOfMemory exceptions. When this happens, the state of the process becomes unreliable, as some vital business logic might not have been executed. Java only has limited options to take action when OutOfMemory exceptions occur.
The Java Service Wrapper however support a monitoring feature that is capable of taking action in case OutOfMemory exceptions occur. The following snippet of configuration will perform a thread dump and then a restart of the Servoy Application Server.
The component is licensed by Servoy to be bundled and used in combination with the Servoy Application Server only. It's not allowed to use the component outside the context of the Servoy Application Server.