Details
-
Bug
-
Resolution: Unresolved
-
Neutral
-
None
-
None
-
None
-
None
Description
Steps to reproduce
- Create a large dam repository on a Magolia 5 instance
- Start Magnolia 6 on that repository
- 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.
Checklists
Acceptance criteria