The HTTP engine uses a configured pool of HttpConnection objects to serve requests and keep HTTP/1.1 connections open between requests. The default pool contains 16 connections. Configure it before constructing HttpServer with HttpServerConfig::setNoOfHttpConnections.

Configure the HTTP pool

size (U16) is the connection count. It must be at least the configured command count plus three and fit in U16.
The setter returns 0 on success or -1 when the count is too small.
Increasing the connection count also raises the configured maximum session count when that value was smaller.
HttpServer allocates the pool during construction. Configuration changes afterward do not resize that server's connection pool.

A larger pool allows more HTTP connections to remain open. It also requires more BAS memory and more resources from the network stack. Request/response buffers are associated with HttpCommand objects; TLS connections can require additional TLS buffers. The HTTP connection count alone is therefore not a complete memory budget.

Account for all sockets

The pool limit applies to connections managed by the HTTP engine. It does not limit separate Lua sockets, HTTP clients, WebSockets after connection takeover, or other application connections. Listener sockets and other dispatcher users also consume network-stack and dispatcher resources.

Choose a pool size that leaves room for these other users. Limits depend on the selected SoDisp port, build configuration, operating system, and TCP/IP stack. A select-based port is constrained by its descriptor-set representation; an epoll-based port has different limits. Do not infer the available socket count from the HTTP configuration alone.

Idle connections and TCP cleanup

When a new connection needs a pool entry, HttpServer_getFreeCon first checks for a free entry and can reclaim an idle connected entry. If needed, it can also terminate a pending request to recover an entry. The pool does not grow automatically.

Keeping HTTP/1.1 connections open avoids unnecessary reconnects. Closing TCP connections can leave protocol state, including TIME_WAIT, in the network stack after the BAS pool entry becomes reusable. Its duration and resource cost are controlled by the TCP/IP implementation. Size the stack and the BAS pool together, using the actual application workload.