-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Medium
-
None
-
Affects Version/s: 10.2.18, 10.2.19
-
Component/s: Search - Indexing, Server - Jobs
-
None
-
4
-
Severity 3 - Minor
-
52
Issue Summary
Out of the box, ContentTreePermissionReindexEventBackgroundSender->process() processes 20 page ids in each batch execution.
When the processing of this batch runs for a long time, other Confluence nodes can potentially also run ContentTreePermissionReindexEventBackgroundSender->process() and process the exact same pageIdsToProcess from background_job row.
This can result in redundant duplicate data set added into journal_entry table.
Steps to Reproduce
- Install a clustered Confluence instance with multiple nodes
- Setup a data set with the following structure:
- Create a new "Base Page"
- Directly under Base Page
- Page1 (800 pages directly under this)
- Under one of the new child pages, create a deep page tree of 1200 pages deep
- Page2 (800 pages directly under this)
- Under one of the new child pages, create a deep page tree of 1200 pages deep
- Page3 (800 pages directly under this)
- Under one of the new child pages, create a deep page tree of 1200 pages deep
- Page1 (800 pages directly under this)
Every single page above should have 1000's of comments added to the page
The aim is to create a large enough data set so that ContentTreePermissionReindexEventBackgroundSender->process() processing of the default 20 page ids takes a long time.- Change the permission on Base Page
- This will result in a ContentTreePermissionReindexEventBackgroundSender added to table background_job
For a long running batch run ContentTreePermissionReindexEventBackgroundSender->process(), processing 20 page ids:
Expected Results
Multiple nodes do not process the same pageIdsToProcess from background_job for the same background_job.id.
Actual Results
Multiple nodes process the same pageIdsToProcess from background_job for the same background_job.id.
This can result in each node adding redundant duplicate data set added into journalentry table.
Manually adding DEBUG to getPortionOfPageIds across each node will show the same IDs processed across each node.
e.g.
NODE 1
2026-10-12 01:54:01.654 [Caesium-1-2] confluencelocalmsb-0 [BYTEMAN] getPortionOfPageIds - IDs selected for this batch (20 items): [163933, 163934, 165268, 165424, 165473, 165630, 166932, 168712, 168872, 168928, 169029, 171898, 175432, 178945, 182493, 186162, 189878, 193407, 1081796, 1085489]
NODE 2
2026-10-12 01:56:24.529 [Caesium-1-2] confluencelocalmsb-1 [BYTEMAN] getPortionOfPageIds - IDs selected for this batch (20 items): [163933, 163934, 165268, 165424, 165473, 165630, 166932, 168712, 168872, 168928, 169029, 171898, 175432, 178945, 182493, 186162, 189878, 193407, 1081796, 1085489]
Workaround
Currently there is no known workaround for this behavior.
- relates to
-
CONFSERVER-104496 Permission reindexing consumes excessive CPU on comment-heavy page trees due to repeated Hibernate autoflush checks
-
- Gathering Impact
-