Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY#99
Draft
Copilot wants to merge 1 commit intomode_simplifiedfrom
Draft
Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY#99Copilot wants to merge 1 commit intomode_simplifiedfrom
Copilot wants to merge 1 commit intomode_simplifiedfrom
Conversation
Copilot
AI
changed the title
[WIP] Fix simplified benchmark runner
Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY
Mar 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Analysis of whether
--mocklessbehavior is correct and equivalent when running underNETTY_SCHEDULERvsVIRTUAL_NETTYmodes.Findings
Both modes are functionally correct and produce identical HTTP responses. The Jackson round-trip work in
doMocklessProcessingis representative —CACHED_JSON_BYTESmatchesMockHttpServer.CACHED_RESPONSEexactly, and thesendResponsepath is identical in both cases.The behaviors are intentionally different in scheduling model:
NETTY_SCHEDULERFifoEventLoopScheduler(carrier = event loop platform thread)VIRTUAL_NETTYNETTY_SCHEDULER detail
threadFactorySupplier = group::vThreadFactoryis evaluated inchannelActive, which runs on the event loop's VT.vThreadFactory()detects the currentFifoEventLoopSchedulerviaCURRENT_SCHEDULERscoped value and returns a factory tied to it. Each connection'sorderedExecutorServicetherefore creates VTs that are pinned to that connection's event loop carrier thread.In mockless mode there is no blocking, so the processing VT runs to completion without parking — the carrier is briefly monopolized for the Jackson work, then the event loop VT resumes and drains the response task queued via
eventLoop.execute().VIRTUAL_NETTY detail
threadFactorySupplier = () -> defaultFactoryalways returns the same default FJP factory. Processing VTs are independent of the event loop VT (ManualIoEventLoopTask). After the VT finishes the Jackson work,eventLoop.execute()enqueues the response task, which the busy-polling event loop VT picks up viarunNonBlockingTasks()on its next iteration.Conclusion
No correctness issue. The scheduling difference between modes is the benchmark's measurement target, not a bug.
💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.