Confluence 8.2 indexing cancellation policy: best-effort to force-stop transition
0 reputation · 14 Jun 2022, 14:07 UTC
Confluence 7.13 introduced the indexing.timeout.ms system property to bound background search indexing jobs, and 8.2 added the indexing.cancellation.policy setting with 'best-effort' and 'force-stop' modes. The default remains 'best-effort', which attempts to interrupt stalled threads but does not guarantee termination if indexing code ignores the interrupt status. Switching to 'force-stop' is intended to enforce the timeout more strictly, yet the documentation notes it may leave index fragments that require manual repair via the Integrity Checker.
Administrators face a configuration boundary between accepting potential overruns under the default policy and risking index inconsistency under force-stop. Because neither mode automatically rolls back partially indexed content, the practical trade-off involves degraded search relevance versus repair overhead. The exact behavior when a long-running indexing task ignores an interrupt under best-effort, and the recovery steps required after a force-stop cancellation, remain version-specific concerns.
For a mixed workload of frequent small edits and occasional large page imports, which cancellation policy minimizes both search degradation and manual repair burden? What verification steps confirm index integrity after a timeout-induced cancellation?