Description
Add upgrade note: revalidate ttlCheckerBatchLimit on 8.7.29+ / 8.8.28+ / 8.9.1+
ttlCheckerBatchLimit (message TTL / expired-message cleanup batch size) has no documentation anywhere in camunda-docs — not in current docs/, not in any versioned docs (8.7, 8.8, 8.9). Only related, and separate, documented setting is camunda.processing.enable-async-message-ttl-checker (bool), which just toggles sync/async TTL checking and says nothing about batch sizing or defaults.
The gap became customer-impacting via support ticket incident-6505 : the expired-message cleanup mechanism changed starting in 8.7.29 / 8.8.28 / 8.9.1, so a previously-tuned low ttlCheckerBatchLimit (e.g. 10) that worked on earlier patch versions caused backpressure/reduced throughput after upgrading to these versions or later. Increasing it to 500 restored expected performance. The current default is 100 (not unlimited).
Motivation
Without documentation, customers who tuned this setting on older patch versions have no way to know:
- that upgrading to 8.7.29+ / 8.8.28+ / 8.9.1+ changes cleanup pacing behavior and old tuned values may no longer be appropriate.
Acceptance criteria
Links
Description
Add upgrade note: revalidate
ttlCheckerBatchLimiton 8.7.29+ / 8.8.28+ / 8.9.1+ttlCheckerBatchLimit(message TTL / expired-message cleanup batch size) has no documentation anywhere in camunda-docs — not in currentdocs/, not in any versioned docs (8.7, 8.8, 8.9). Only related, and separate, documented setting iscamunda.processing.enable-async-message-ttl-checker(bool), which just toggles sync/async TTL checking and says nothing about batch sizing or defaults.The gap became customer-impacting via support ticket incident-6505 : the expired-message cleanup mechanism changed starting in
8.7.29/8.8.28/8.9.1, so a previously-tuned lowttlCheckerBatchLimit(e.g.10) that worked on earlier patch versions caused backpressure/reduced throughput after upgrading to these versions or later. Increasing it to 500 restored expected performance. The current default is 100 (not unlimited).Motivation
Without documentation, customers who tuned this setting on older patch versions have no way to know:
Acceptance criteria
ttlCheckerBatchLimit, revalidate it before/after upgrading to8.7.29+,8.8.28+, or8.9.1+— cleanup pacing changed, low values (e.g.10) can cause backpressure.ttlCheckerBatchLimitconfig reference entry (once added) so someone landing on either page finds the other. The following should also be documented:Links