Skip to content

Clarify Dispatcher executor sizing requirements in KDoc#9454

Open
leno23 wants to merge 1 commit into
square:masterfrom
leno23:docs/dispatcher-executor-requirement
Open

Clarify Dispatcher executor sizing requirements in KDoc#9454
leno23 wants to merge 1 commit into
square:masterfrom
leno23:docs/dispatcher-executor-requirement

Conversation

@leno23
Copy link
Copy Markdown

@leno23 leno23 commented May 25, 2026

Summary

  • Expand the Dispatcher class KDoc to explain that an executor sized exactly to maxRequests is not sufficient when paired with SynchronousQueue.
  • Document why the default executor uses maxPoolSize=Int.MAX_VALUE and suggest safe alternatives (2 × maxRequests or a queueing executor).

Fixes #9443

Problem

The previous wording ("should be able to run maxRequests number of calls concurrently") led users to configure ThreadPoolExecutor(maxRequests, maxRequests, ..., SynchronousQueue), which can reject submissions with InterruptedIOException("executor rejected") under sustained load. This happens because promoteAndExecute() submits the next promoted call from a worker thread before it returns to the queue.

Test plan

  • Documentation-only change; no runtime behavior change
  • KDoc renders correctly in generated docs

The previous wording implied that an executor sized to maxRequests is
sufficient. In practice, promoteAndExecute() submits the next call from
a worker thread before it returns to the queue, which can cause
RejectedExecutionException with SynchronousQueue and a fixed-size pool.

Fixes square#9443

Co-authored-by: Cursor <cursoragent@cursor.com>
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.

Dispatcher Javadoc understates the executor requirement ("should be able to run maxRequests concurrently" is necessary but not sufficient)

1 participant