Closed CRC-Mismatch closed 6 months ago
There appears to be a race condition which is releasing an HTTP/2 stream within a callback which later releases the same string. The hang may be then due to the unexpected exception, though I'm not certain.
I pushed a branch, https://github.com/amphp/http-client/compare/5.x...issue-361, which a quick fix for checking if the stream was previously released before attempting to release it again. Can you change your dependency on amphp/http-client
to dev-issue-361
and see if the hang still occurs?
For some context, I've developed a Symfony Console command for a data migration task that requires basically just sending POST requests to a predefined endpoint and logging the results of each request - but since it's a mass-import task, we'll be doing around 1M of these POSTs. The command itself uses AMPHP's Pipelines and Workers to easily speed up the process, and inside the custom Task class, I'm using amphp/http-client to do the actual request/response handling.
Now on to the problem itself: It seems that whenever a connection breakage occurs, the affected
amp-process
subprocess "spits" out some PHP warnings, then deadlocks using 100% of a CPU core. The remaining subprocesses are able to continue the batch just fine, until there's only the tasks that were already assigned to the locked process' workers remaining - then the whole command sits running "idle" until manually interrupted (SignalCancellation seems to do the trick), and only then a really long "Fatal Error" trace gets printed out...The "initial" PHP warnings:
The traces that only get printed after the Cancellation request:
php -i
summary:Composer packages versions: