Skip to content

Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY#99

Draft
Copilot wants to merge 1 commit intomode_simplifiedfrom
copilot/sub-pr-97
Draft

Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY#99
Copilot wants to merge 1 commit intomode_simplifiedfrom
copilot/sub-pr-97

Conversation

Copy link
Contributor

Copilot AI commented Mar 23, 2026

Analysis of whether --mockless behavior is correct and equivalent when running under NETTY_SCHEDULER vs VIRTUAL_NETTY modes.

Findings

Both modes are functionally correct and produce identical HTTP responses. The Jackson round-trip work in doMocklessProcessing is representative — CACHED_JSON_BYTES matches MockHttpServer.CACHED_RESPONSE exactly, and the sendResponse path is identical in both cases.

The behaviors are intentionally different in scheduling model:

Mode Processing VT scheduler Concurrency model
NETTY_SCHEDULER Netty FifoEventLoopScheduler (carrier = event loop platform thread) Processing VTs and event loop VT interleave sequentially on one carrier
VIRTUAL_NETTY Default ForkJoinPool Processing VTs run concurrently with the event loop VT on separate FJP carriers

NETTY_SCHEDULER detail

threadFactorySupplier = group::vThreadFactory is evaluated in channelActive, which runs on the event loop's VT. vThreadFactory() detects the current FifoEventLoopScheduler via CURRENT_SCHEDULER scoped value and returns a factory tied to it. Each connection's orderedExecutorService therefore 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 = () -> defaultFactory always 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 via runNonBlockingTasks() 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.

Copilot AI changed the title [WIP] Fix simplified benchmark runner Scrutiny: mockless mode correctness across NETTY_SCHEDULER and VIRTUAL_NETTY Mar 23, 2026
Copilot AI requested a review from franz1981 March 23, 2026 10:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants