Maximum reservation timeout in seconds for adaptive scaling (default: 1800).
This is the ceiling for the adaptive reservation timeout — how far the
system is allowed to stretch under sustained load. The adaptive logic
only uses what it needs based on stream depth; this value defines the
upper bound, not the steady state.
The tradeoff is recovery time after a consumer crash: if a consumer
reserves a message and dies, that message is unavailable until the
timeout expires. A higher ceiling means longer recovery from crashes
but prevents duplicate delivery under heavy sustained load.
In practice, crashes are rare and the delay is bounded. The cost of
a ceiling that is too low — duplicate delivery, collation errors,
wasted CPU, workflow stalls — is far higher than a slightly longer
recovery window after a crash.
Tuning guidance:
Dedicated infrastructure with ample CPU: lower ceiling is fine (600s)
Shared/multi-tenant or CPU-constrained: use the default (1800s)
Long-running batch imports or large workflow graphs: increase (3600s+)
Cloud deployments without CPU contention: the adaptive logic will
naturally stay near the starting timeout and rarely approach the ceiling
Maximum reservation timeout in seconds for adaptive scaling (default: 1800).
This is the ceiling for the adaptive reservation timeout — how far the system is allowed to stretch under sustained load. The adaptive logic only uses what it needs based on stream depth; this value defines the upper bound, not the steady state.
The tradeoff is recovery time after a consumer crash: if a consumer reserves a message and dies, that message is unavailable until the timeout expires. A higher ceiling means longer recovery from crashes but prevents duplicate delivery under heavy sustained load.
In practice, crashes are rare and the delay is bounded. The cost of a ceiling that is too low — duplicate delivery, collation errors, wasted CPU, workflow stalls — is far higher than a slightly longer recovery window after a crash.
Tuning guidance: