THRIFT-6243: Grow the TNonblockingServer read buffer as the payload arrives

[Jens-G]

TNonblockingServer's TConnection reserved the whole declared frame the moment it read the four-byte length prefix: transition() reallocated the read buffer to the frame size before any payload byte had arrived, so a peer could make the server reserve up to getMaxFrameSize() bytes per connection by sending only a four-byte header. (The reservation is address space — a std::realloc — rather than resident memory, but it is still an unamplified header-to-allocation step.)

This bounds the allocation by what the peer actually sends:

• transition() reserves only enough to hold the length prefix and begin reading (the prefix plus about a kilobyte), not the declared frame.
• The buffer grows toward the frame size in SOCKET_RECV as bytes are actually read — by the same doubling the up-front allocation used, now driven by what the peer sends, with the doubling guarded so it cannot overflow uint32_t.

A frame that fully arrives ends at the same buffer size as before, so there is no change for legitimate traffic in the steady state, and no change at all for frames of a kilobyte or less. A header with no payload reserves next to nothing. A large frame that does arrive now pays the amortized doubling copy any grow-as-you-go buffer pays.

The uint32_t overflow guard in the new growReadBuffer helper is a small addition the old inline doubling lacked (the old newSize *= 2 would loop forever for a maxFrameSize above 2 GiB); it is included here — happy to split it to its own ticket if a reviewer prefers.

Test

Four cases in TNonblockingServerTest: a Linux-only, forked case asserts that a 256 MiB frame header with no body does not grow the server's VmSize; two portable cases drive multi-megabyte requests that are assembled over many libevent callbacks (the buffer doubling as bytes arrive) and must round-trip byte-for-byte, one freeing the grown buffer at connection close and one between frames on a live connection; and a portable case writes two requests in a single send and checks that both are answered, so each read stops at the end of its own frame even when the buffer is larger than the frame.

Related

This is part (4) of the nonblocking-server frame handling; part (2)+(3), wiring the server to TConfiguration, is THRIFT-6242 (#3846, merged), and this branch is rebased onto it. This revision also stops each read at the end of the current frame (the buffer can be larger than the frame, and the previous revision could read into a following request) and spells the new min calls (std::min) so the change compiles with MSVC.

---

Prepared with AI assistance (Claude Opus 4.8).