STTNet 0.7.0

Chapter 20: Integration and Production Checklist

This chapter covers project integration, resource boundaries, observability, graceful shutdown, and rollback checks for production deployment.

1. Build and dependencies

Project integration uses the CMake target STTNet::sttnet rather than copied source files. Deployment builds use Release settings, while separate Debug/ASan builds cover regression testing.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
ctest --test-dir build --output-on-failure
  • The runtime environment includes JsonCpp, OpenSSL, pthread, and the remaining linked dependencies.
  • Certificates, keys, log directories, and configuration are supplied through deployment settings rather than development-machine paths.
  • The STTNet upgrade workflow includes protocol interoperability and application regression tests.

2. Network and operating-system resources

Framework capacity settings leave Linux limits unchanged. The deployment checklist includes:

AreaWhat to verify
File descriptorsulimit -n, systemd LimitNOFILE, and expected connections
Listen queuelisten_backlog and kernel somaxconn
Write backpressurePer-connection pending bytes, write budget, and slow-client policy
WorkerPoolThread count, pending-task limit, and database/RPC timeouts
HTTP inputHeader, body, upload, and business-field size limits
TLSCertificate expiry, key permissions, protocol versions, and mTLS policy

Related chapters: Server Settings and Security and Input Boundaries.

3. Data, logging, and secrets

  • JSON parse failures map to a clear 4xx response, and unvalidated fields are not read on the failure path.
  • Monitor dropped asynchronous log entries and keep the logger alive through shutdown.
  • Logs exclude passwords, tokens, cookies, private keys, and complete request bodies by default.
  • Base64 is encoding, not encryption; review the limits of SHA-1 and AES-CBC.
  • External input is validated for size, format, and authorization before it reaches workers or business code.

Related chapters: JSON, Files and Logging, and Encoding and Crypto Utilities.

4. Process lifecycle

  1. SIGINT (2) and SIGTERM (15) are blocked before thread creation.
  2. Logger, server, Reactor, and Worker objects are created.
  3. The listener starts together with health and metrics endpoints.
  4. A termination signal stops new accepts and begins draining in-flight work and pending writes.
  5. The configured timeout bounds normal shutdown; an external supervisor may escalate to SIGKILL (9) after the grace period.

Process provides process launch and restart, not complete Unix daemonization. Production deployments commonly use systemd, containers, or a dedicated supervisor for full lifecycle management. Related chapters: Linux Signals and Process Supervision.

5. Release Conditions

Release principle: Load-test the slowest realistic business path before focusing on empty-response QPS. Capacity is determined by business logic, downstream dependencies, and tail latency.