Common issues

Host resolution

Some environments have issues with host resolution between servers and this can cause issues with the Platform. It typically happens in environments where all the hostnames aren't resolvable, e.g. cloud provisioned servers or processes launched under Kubernetes.

Support has been added for more configurable host resolution when registering with Control and the Messaging Server. Previously the registering host used in both cases was derived by the system and provided no options to customize.

Control

The host a process registers with is used in order for other processes or clients to communicate with it. By default the process attempts to derive a FQDN using a combination of kdb+ and system commands. Using instance configuration, via the INSTANCE_CONFIG parameter, the registration value can be modified. There are two modes; deriving a different host or using custom logic.

The former approach is done using the .ex.i.regHostMode parameter.

  • IP - registers with the local IP address, returned by .utils.getlocalip[].
  • ZHOST - uses the hostname, returned by .z.h.

Custom logic can be used by creating an instruction to run at start-up and calling the .ex.setRegHost API and the desired hostname.

Messaging

The registration host is used for components to connect with each other. By default the MS resolves this value from the remote IP when a process registers. In a similar manner as for Control, the value can be configured in two ways; instance configuration or custom logic.

The former is done using the .dm.i.regHostMode parameter.

  • IP - register using the local IP address, returned by .utils.getlocalip[]
  • host - uses the process-derived host name, returned by .utils.gethost[]

Custom logic can be used by creating an instruction to run at start-up and calling .dm.setRegHost with the desired hostname.

The screenshot below shows a basic example of host to use custom logic to set the hostname for both Control and Messaging.

Screenshot