Skip to content

What's new in v3

This page summarizes the major differences between KX Sensors v2 and v3, to help developers and system administrators accustomed to v2 get oriented.

KX Sensors v3 is a major rewrite of the platform. It removes the Delta Control and Delta Stream layers that v2 was built on and replaces them with lighter, more responsive KX Sensors framework components that scale to larger and more dynamic deployment topologies.

Architecture and processes

  • The Delta Platform is gone. Processes such as Delta Control, Messaging Server, Query Router, Query Processor, and Ops no longer exist and are replaced by improved equivalents. Process startup is now largely asynchronous and parallelized, rather than following the old workflow model.
  • A new Discovery service, based on the distributed key-value store etcd, replaces the old discovery mechanism. Familiarize yourself with etcd and its CLI, etcdctl.
  • A new enterprise messaging system, Reliable Transport (RT), persists messages to disk and guarantees delivery order using the Raft consensus algorithm. In v3.0 through v3.2, the main RT processes run as Docker containers. From v3.3, they run natively and Docker is no longer required.
  • New Gateway (GW), Response Process (RP), and Synchronous Gateway (SGW) service classes replace the v2 Query Router, Query Processor, and QrGW, with better performance and robustness.
  • A new Message Queue (MQ) service class consumes an RT stream and guarantees each message is processed at least once by one of its registered consumers, unlike the one-to-many delivery of a publish/subscribe model.

Deployment, licensing, and operations

  • A new command-line interface, kxsctl, replaces the deprecated Delta web UI for operating and automating KX Sensors instances.
  • KX Sensors processes are installed as systemd services on Linux, so they restart automatically, for example after a server patch and reboot. Familiarize yourself with systemd and systemctl.
  • The installer is simpler, and ships with an updated Deployment Guide.
  • New prerequisites are required: etcd for Discovery, and, in v3.0 through v3.2, Docker with Docker Swarm for RT in multi-node deployments. From v3.3, RT no longer requires Docker.
  • Networking has changed. In addition to TCP, KX Sensors now uses UDP and multicast for interprocess communication, so validate multicast support on your network. Connections between Response Processes and external SAPI clients are now initiated by the server, which usually requires new firewall rules. KX recommends increasing the MTU to 65,535 bytes to avoid IP fragmentation.
  • etcd and RT both use the Raft consensus algorithm, which requires an odd number of nodes. Other KX Sensors components don't have this requirement.
  • Licensing is consolidated: a single kdb+ license covers a multi-node deployment, replacing the separate kdb+ and Delta Platform licenses that v2 required. However, v3 gates individual features behind license feature flags, so depending on the features you use — RT in a multi-node deployment, KX Dashboards, or REST — your license may need to be reissued with additional flags. From v3.3, KX Sensors runs on KDB-X rather than kdb+, and your existing license continues to work, subject to the same feature flags. To have a license reissued, contact KX.
  • Watches and alerts are improved. You can monitor log messages and statistic thresholds, and route alerts to an HTTP destination, including for HA events like failover and failback.
  • netcon and HAProxy are no longer required. Fast network failure detection is now built into KX Sensors code directly, and the v2 single-primary bottlenecks that HAProxy compensated for no longer exist in v3.

Developer-facing changes

  • Code and configuration are stored as plain-text q files and YAML instead of XML, making them easier to edit and diff. Schemas are now defined per table in YAML, and configuration objects such as nxNodeConfig and kxsSAPI are replaced by etcd, manifest.yaml, and per-API YAML files.
  • Entity prefixes such as kxs and nx are no longer required on core code files and schemas, since the v3 package directory structure differentiates them.
  • KX Sensors doesn't enforce a particular source code management system. If you use Git, use it natively or with the tool of your choice.
  • REST support, unavailable in v3.0 through v3.2, was reinstated in v3.3. You can expose your public APIs as JSON-over-HTTP endpoints — see Call APIs over REST.

Client-side (SAPI) changes

  • SAPI is reimplemented with a centralized C core; the C# and Java implementations are thin layers around it.
  • The interface is streamlined: callAPI and callFunction are combined into a single execute method.
  • SAPI no longer throws exceptions. Methods return a boolean to indicate success and populate a response object with an application code, response code, and other detail fields.
  • Discovery and RT are integrated into SAPI under the hood, for retrieving connection information and reliably publishing messages to SDLs.

What's unchanged

Many service classes work just as they do in v2, including SDLs, DBs, MDLs, DBW, and VEE. Your existing schemas, APIs, and code will largely migrate with minimal change.

Moving from v2 to v3

KX recommends the following process when moving development from v2 to v3:

  1. Learn: review the v3 documentation, the Deployment Guide, and the kxsctl help pages.
  2. Install: set up a vanilla v3 instance for hands-on learning.
  3. Convert packages: convert the XML in your v2 packages to the q and YAML representation required by v3, using the KX Sensors 2.x-to-3.x package conversion script as a starting point. Some manual changes are typically still required.
  4. Convert external clients: update your C# or Java clients to use the new SAPI.
  5. Deploy and test: deploy your converted packages and clients, and run regression tests.
  6. Update automation: update your CI and other scripts to use the new installer and CLI.

Note

If you need the KX Sensors 2.x-to-3.x package conversion script or the full upgrade guide, contact KX.

Next steps