Skip to content

[GSoC 2026] Kafka Streams runner: separate source poll size from bundle size, expose the session timeout - #39748

Merged
je-ik merged 1 commit into
apache:feat/18479-kafka-streams-runner-skeletonfrom
junaiddshaukat:feat/ks-bundle-and-session-options
Aug 14, 2026
Merged

[GSoC 2026] Kafka Streams runner: separate source poll size from bundle size, expose the session timeout#39748
je-ik merged 1 commit into
apache:feat/18479-kafka-streams-runner-skeletonfrom
junaiddshaukat:feat/ks-bundle-and-session-options

Conversation

@junaiddshaukat

Copy link
Copy Markdown
Contributor

Summary

Part of #18479. Two pipeline options that came out of trying to measure how the runner behaves under load, and that are worth having whatever the measurement ends up looking like.

How much a source reads is not how big a bundle is

ReadTranslator took the unbounded source's per-poll limit from --maxBundleSize. They are different concerns: a small bundle is how output arrives promptly, while how much a source reads at a time is about throughput. Sharing one setting means a pipeline cannot ask for both — lowering the bundle size to get prompt output also throttles the source to a couple of elements per poll.

--readMaxElementsPerPoll (default 1000, what the source effectively had before) separates them.

The recovery knob was unreachable

How quickly work moves to another instance after one is lost is bounded by how quickly the consumer group notices, which is session.timeout.ms. The runner never set it, so it was Kafka's default of 45 seconds and a pipeline had no way to ask for anything else.

--sessionTimeoutMs exposes it, keeping Kafka's 45s default so nothing changes for an existing pipeline. Lowering it trades tolerance of a slow or briefly paused instance for quicker recovery, and a broker will refuse a value below its own group.min.session.timeout.ms, which itself defaults to 6s — so this is not a knob that can be turned arbitrarily far.

The heartbeat is derived as a third of the timeout rather than exposed separately. Kafka rejects a heartbeat that is not shorter than the session timeout, so deriving it keeps the pair consistent however the timeout is set; a third is the ratio Kafka's own defaults use.

Testing

./gradlew :runners:kafka-streams:build # 103 unit tests, spotless + checker + errorprone
./gradlew :runners:kafka-streams:validatesRunner # 59 tests

KafkaStreamsPipelineRunnerConfigTest covers the default, the override, the ratio, and that the heartbeat stays shorter than the timeout across a range of values. That last one is not decoration: the derivation first had a fixed 200ms floor, which produces a heartbeat equal to the timeout at 200ms and would be rejected by Kafka. The test fails if that floor is put back.

…m the bundle size, and expose the session timeout
ReadTranslator took the unbounded source's per-poll limit from --maxBundleSize.
They are different concerns: a small bundle is how output arrives promptly,
while how much a source reads at a time is about throughput. Sharing one
setting means a pipeline cannot have both, since lowering the bundle size to
get prompt output also throttles the source.
--sessionTimeoutMs exposes how long the consumer group waits before deciding
an instance has gone, which is the floor on how quickly its work moves
elsewhere. Kafka's 45s default is kept. The heartbeat is derived as a third of
it rather than exposed separately, because Kafka rejects a heartbeat that is
not shorter than the timeout and deriving it keeps the pair consistent.

@je-ikje-ik left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@je-ik
je-ik merged commit 511a40e into apache:feat/18479-kafka-streams-runner-skeletonAug 14, 2026
2 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@junaiddshaukat@je-ik