Closed segrax closed 8 months ago
Hey @segrax 👋 Thanks for the report 👍 I'll investigate the problem.
Looks like, that worker returned to the pool in the ready
state, but actually, by some reason, doesn't really located in the pool... Really interesting case.
Ok, firstly, I found a problem why exec_ttl
had no power in your case (will be fixed, from the RR side). Secondly, I found a problem why worker hangs on fwite
(and this needs to be fixed from the PHP side).
The fix will be released next Thursday.
That's great news! Appreciate the swift response @rustatian
No duplicates 🥲.
What happened?
When a browser disconnects early while receiving a response streamed from PHP, the worker / PHP can lock up.
The worker never recovers by itself
The chunk size heavily effects the chance of this occurring (eg. 512000 bytes is likely to lockup first try, where as 512 bytes could take 100s of attempts, and 51200 bytes will lockup within a few)
This is a dump of the last ~100 executed PHP functions/class methods executed by the php process, the final instruction is where the process is left stuck: fwrite(Unknown Type, '', 51216)
This is execution of "Spiral\RoadRunner\Http\HttpWorker::respondStream" (first instruction here is line 125: $body->next();)
Version (rr --version)
2023.3.8 (build time: 2023-12-14T16:05:26+0000, go1.21.5), OS: linux, arch: amd64
How to reproduce the issue?
The worker.php below is almost identical to the example provided in the documentation, except its reading from a large (5gb) file (DIR . '/IMG_0192.MOV') -- size only important to the point of giving you enough time to cancel
rr.yaml
worker.php
Relevant log output