Jens-G opened a new pull request, #3846:
URL: https://github.com/apache/thrift/pull/3846

   `TNonblockingServer` kept its own frame-size limit (`maxFrameSize_`) and 
created every accepted socket with no `TConfiguration`, so an operator who 
configured a maximum frame or message size got no effect on the nonblocking 
server: it enforced only its own frame-size ceiling, and each accepted socket 
used the default 100 MB message budget. `TConfiguration` appeared in 
`TNonblockingServer` only as the source of the default frame-size constant 
(THRIFT-6183).
   
   This wires the nonblocking server to a `TConfiguration`, following the 
precedent that the configuration is the authority (THRIFT-6182 for the 
transport layer, THRIFT-6183 for this server's default):
   
   - The server holds a `std::shared_ptr<TConfiguration>`; `getMaxFrameSize()` 
/ `setMaxFrameSize()` operate on it, so there is one source of truth for the 
frame-size limit.
   - The configuration is handed to every accepted socket through the server 
transport (`TNonblockingServerTransport::accept()`), covering both the plain 
and TLS server sockets, so the operator's message-size limit bounds each 
connection and the layered transports built on top of it.
   - A frame larger than the configured maximum message size is refused before 
the read buffer is grown for it, next to the existing frame-size check.
   
   Along the way, `TTransport::setConfiguration()` is corrected to re-seed the 
message-size budget (it previously swapped the pointer without re-seeding, so a 
configuration installed after construction never took effect); it has no 
callers within the library. `setMaxFrameSize()` clamps to `INT_MAX`, since 
`TConfiguration` stores the frame size as `int`.
   
   ### Compatibility (breaking)
   
   An operator who sets a `TConfiguration` with a maximum below what the server 
accepted before will start closing those connections — that is the point of 
honouring the configuration. Default behaviour is unchanged (a default 
`TConfiguration` carries the same 16,384,000 frame size and 100 MB message size 
the server used before).
   
   ### Test
   
   Three cases added to `TNonblockingServerTest`: a frame above a configured 
maximum frame size is refused; a frame above a configured maximum message size 
(but below the frame ceiling) is refused before the buffer is grown; and a 
generous configuration still serves ordinary traffic.
   
   ### Related
   
   This is part (2)+(3) of the nonblocking-server frame handling. Part (4), 
growing the read buffer as the payload arrives, is **THRIFT-6243** — an 
independent PR, not stacked on this one, but it also touches 
`TNonblockingServer.{h,cpp}`, so whichever lands second will need a small 
rebase.
   
   ---
   Prepared with AI assistance (Claude Opus 4.8).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to