Connection pool and proxy

[mostafa]

Proposal
This feature serves a few different purposes and is a core feature. Plugins can extend this functionality to add other types of pools, queues and features.

• Connection pools:
  • Client-side:
    • Connection from DBMS drivers to GatewayD, like psycopg2 (in Python) or the psql client.
    • Manages keep-alives from client(s). See database connection control functions from PostgreSQL docs.
    • Elastic pool:
      • Grows on-demand: using goroutines and multiple CPU cores (via gnet/v2)
      • Has soft/hard limits: configurable, uses system rlimit values if not given, log a warning if soft limit is reached and close connections if hard limit is reached (should find a better way to handle the soft to hard limit using queues?).
      • Rejected/queued upon exhaustion of resources: currently connections will be rejected if the hard limit is reached. Queuing is the next step.
      • Can they have keep-alive? TCP keep-alives are supported. Keep-alive packets can be implemented using gnet.Ticker. Should make it configurable.
      • Where should the client connection configuration be handled:
        1. when parsing packets
        2. on connection initiation
      • Make connections generic: renamed PostgreSQLServer to Server.
  • Server-side:
    • Connections from GatewayD to DBMSes, like PostgreSQL.
    • Sends keep-alive using either SELECT 1; or a better mechanism to see if the connection is still alive, otherwise restarts the connection.
    • Basic connection
    • Predefined pool:
      • Has a fixed number of connections upon start.
      • Answers new connections when exhausted with two responses:
        • Rejects client connection outright with an error.
        • Queues client connection to process it as soon as a server connection gets freed. OUT OF SCOPE
    • Elastic pool:
      • Grows in response to number of client connections and other possible metrics.
      • A normal 1:1 connection pool where the incoming client connections are usually the sole factor for creating a new on-demand server connection.
      • Grows linearly, until exhaustion of resources or some soft/hard limits on both client and server-side.
• Connection proxy:
  • Passive proxy: a zero-copy proxy with (almost) no control over the data, and just pure connection management and bouncing. It can be used to add better connection management and observability over the client/server connections. OUT OF SCOPE
  • Active proxy: an extensible proxy using plugins that can observe, manipulate and process everything, including the data. It has hooks for various parts of the system that plugins can tap into and process incoming/outgoing traffic on both sides.
• Routing: (needs review) OUT OF SCOPE
  • Route connections between client(s) and server(s) based on certain criteria. It determines how the connections from client and server pools should be connected together.
  • In a distributed manner, one can also reason about how different instances of GatewayD relay connections between each other.
• Load balancing (needs review) OUT OF SCOPE

Resources

• panjf2000/gnet

[mostafa]

This ticket should be revisited and all the OUT OF SCOPE parts should become separate issues.