feat(dispatch): add contextual dispatch logic#9687
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Security Scan Results for PRDocker Image Scan Results
Source Code Scan Results🎉 No vulnerabilities found! |
✨ Benchmark results
⚡ Benchmark Comparison
|
b0892b1 to
70273eb
Compare
Swoole
dispatch_funcgets called multiple times during a request lifecycle:The underlying TCP connection is shared between all Swoole processes and it's not guaranteed that the
dispatch_funcis called on the same process all the time.The previous implementation returned a random workerId when there was no data as part of the request. This happens during connection close phase. Debugging the trace here showed the
dispatch_funcgetting invoked over and over again. This caused really high CPU load.It seems Swoole expects the same workerId during connection close that was initially assigned during the connection establish phase. This means we need to bind the assigned workerId to the current
$fdand useDISPATCH_UIDMOD.