-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
6.4.3, 6.6.3, 6.6.6
-
33
-
Severity 2 - Major
-
11
-
There are a lot of problems with moving large page trees via 'Move' feature. It usually takes a lot of time and can easily fail if any concurrent modifications from users are happening. The reason of time complexity if the fact that the whole move is executed in single DB transaction. Due to hibernate autoflush it can take O(N^2) operation because of persistence context scanning.
Another problem is that move feature emits a ton of PageMoveEvents that are used to update various stuff (links, attachments, index). If the listener of the event fails, the system prints the error in log and continues move. These failed event listeners lead to system inconsistencies. For example links between pages might be corrupted or attachments not available.
Basically, it is impossible right now to execute large move operation (tens of thousands of pages) and get successful results from the first run. This feature should be redesigned so that it becomes more stable on large customer instances.
What workarounds are used right now by big customers:
- unlink the instances from load balancer to ensure no concurrent modifications are hapenning
- restrict affected spaces so that no one modifies pages there
- use API instead of UI because UI timeouts after couple of minutes (with backend operation still running)
- split initial move to batches to make it more managable
- go to safe mode so that plugins don't fail on listening PageMove events
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Gathering Impact
-
-
CONFSERVER-40454 Improve the performance of the page tree expansion on the Move Page dialog
- Gathering Interest
- links to
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-