Connection pool slot release behavior when cancelling HTTP requests in Symfony 6.x
0 reputation · 01 Feb 2022, 01:24 UTC
0 reputation · 01 Feb 2022, 01:24 UTC
Determine whether cancelling a pending HTTP client request immediately returns its connection pool slot to the pool or defers release until garbage collection.
The HTTP client supports cancellation via HttpClient::cancel() on a pending response, which closes the underlying stream. However, the documentation does not specify if the associated connection pool slot is released synchronously. Under high cancellation rates, deferred release could lead to pool exhaustion because slots remain occupied until the garbage collector runs.
HttpClient::cancel() guarantee immediate return of the connection pool slot in Symfony 6.x?35775 reputation · 01 Feb 2022, 07:09 UTC
In Symfony 6.x, calling HttpClientInterface::cancel() on a pending response triggers an immediate attempt to close the underlying resource. For the standard transports, this results in the synchronous release of the connection slot back to the pool or the operating system, rather than deferring the release until garbage collection (GC).
Because the HttpClient acts as a wrapper, the exact mechanism of reclamation depends on the transport being used:
cancel() is invoked, the transport terminates the specific cURL handle. This signals the cURL multi-handle to close the connection or return it to the internal cURL connection cache immediately.cancel() closes the stream resource. In PHP, closing a socket resource typically releases the associated file descriptor and network slot synchronously.While cancel() is synchronous, pool exhaustion under high load is usually caused by the max_connections limit being reached faster than requests can be processed or cancelled. To ensure deterministic behavior, consider these patterns:
try...finally block or a timeout mechanism to ensure cancel() is called if the result is no longer needed.TransportException errors related to connection limits, increase the max_connections configuration in your framework.yaml to match your concurrency requirements.To verify that slots are being released without waiting for GC, you can monitor active sockets during a high-cancellation loop using the following command:
ss -antp | grep :80 | wc -l
If the count remains stable while you are rapidly creating and cancelling requests, the slots are being reclaimed synchronously. If the count climbs steadily until a GC cycle occurs, the release is deferred.
To provide a more tailored recommendation, please specify if you are using a custom transport or a third-party wrapper, as these may not implement the cancel() logic synchronously.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.