Skip to content

Service runtime

Control UI

Multiple instances of a service class may be running at the same time. Process names, if not provided, are generated by the system.

  1. To run a service, press the Run button. The dialog that appears shows the possible hosts the service class can run on, plus the other options that will specify to this particular run. If any values are provided for a run, they are remembered and appear in subsequent run dialogs for this particular Service class.

    Screenshot

  2. After running two times, the Process Library Status Viewer should show two services of the class with auto-generated names.

    Screenshot

  3. The additional parameters box allows users to add or override parameters for this particular service. The specified parameters will bepassed to the running service on the command line as seen in the example. The logfile, taskset and listening port can also be overridden. The port field allows users to either define a specific port number or a port range, e.g. 4003 / 4000-5000.

    Screenshot

    q q/prcl.q_ -class FileWatcher_ServiceClass -isservice .. -pollInterval 45

Running services

Within the KX Control UI, services behave similarly to instances. They can be stopped, the log files can be viewed, there is revision history, analytics can be assigned or pushed to the process, and the running service class can be opened in the KX Analyst IDE.

Service scripts

In addition to launching and stopping services from the UI, these operations can be performed on the command-line and automated via the scripts.

Starting services

The following scripts can be used to launch services.

  • Linux: startService.sh
  • Windows: startService.bat

The script parameters are described below;

parameter required example description
-i Y fx_dl Service class name
-n N fx_dl_1 Process name
-t N "1-3" Core affinity/taskset
-l N fx_dl_1.out.log Process log
-a N "-pollInterval 45" Parameter overrides
-d N Debug mode (run interactively)

Windows affinity

On Windows, the core affinity must be specified using a hexadecimal mask instead of the Linux taskset format. Please see here for more information.

From the Control UI, Linux format is fine as Control will convert it.

Examples

# start with name
./startService.sh -i fx_dl -n fx_dl_1

# start with overrides and taskset
./startService.sh -i fx_dl -a "-pollInterval 45" -t "1-3"

Parameter overrides

The following parameter types can be overridden;

  • Service params - these are the parameters dictated by the process template
  • Reserved params - these all have a dc_ prefix and the complete list is available in the .pl.parameterreserved table on Control
  • Additional params - these correspond to the values available in the INSTANCE_CONFIG.

Port assignments

To set the port of a process at runtime when using the script, the user should use the -a argument.

# start with port
./startService.sh -i fx_dl -a "-dc_port 5001"

# start with port range
./startService.sh -i fx_dl -a "-dc_portrange 5000-6000"

Port assignment

If a port isn't assigned by the user, the service will automatically assign one on start-up. This uses the kdb+ ephemeral port logic.

Stopping services

The following scripts can be used to stop services.

  • Linux: stopService.sh
  • Windows: stopService.bat

It can be used to stop a single service or all services for a class.

Examples

# stop class
./stopService.sh -i fx_sandbox

# stop service
./stopService.sh -n fx_sandbox_1981

Optional parameters

When launching services using the Control UI or the script, some of the parameters are optional. The default behavior for each, if not specified, is described below.

  • Service name: a name will be auto-generated when the process registers with Control. It will be a combination of the service name plus a counter, e.g. fx_dl_1234

  • Core affinity:

    • UI: processes will inherit the affinity of their parent (either Control or the Control daemon)
    • Script: it will use the value of ${KDB_CPU_AFFINITY}.

  • Logfile: if using a named service is provided, the logfile will be prefixed with this name fx_dl_1.${time}.out.log. Otherwise the class name will be used fx_dl.${time}.out.log

Command-line parameters

Different behavior

A number of parameters to kdb+ processes are set-able from the command-line only. For service classes defined with these enabled, there is a difference in behavior when launching from the script.

When launching from services using the script, the values set for the service class will not be used. The user must specify the desired values themselves. The following Reserved parameters correspond to kdb+ command-line parameters and need to be handled specially.

parameter kdb+ default
Number of Secondaries -s none
No Client System Calls -u disabled
Memory Limit -w none
TLS -E disabled

Example

The fx_dl service class is defined with TLS set to mixed and a memory limit of 100MB. The command to launch is below;

./startService.sh -i fx_dl -a "-E 1 -w 100"
Back to top