[MAGNOLIA-8342] RenamePropertiesTask causes OutOfMemory during upgrade to Magnolia 6 Created: 08/Mar/22  Updated: 04/Jul/23

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Rico Jansen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Team: Nucleus

 Description   

Steps to reproduce

  1. Create a large dam repository on a Magolia 5 instance
  2. Start Magnolia 6 on that repository
  3. Wait until java runs out of memory.

Further tracing found out that the RenamePropertiesTask was the one causing this.

With the debugger I found out that the query that was started was:

SELECT
* FROM [nt:base] AS t WHERE (ISSAMENODE(t, '/') OR ISDESCENDANTNODE(t, '/'))
AND t.[mgnl:lastTaggedDate] is not null

This comes from the DamJcrVersionHandler so this query is executed on the dam workspace. Ours is very large so this query never returns.

Testing the query on another instance on the config workspace shows that on that small workspace it already takes 2.5 seconds. Which is an age considering the property does not exists there. Removing either one of the OR clauses fixes the problem.

In that case it runs in less then 50ms on our dam workspace. You have to run the query twice (once for each clause). But that still completely dwarves the runtime of the original.

 


Generated at Mon Feb 12 04:31:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.