Hi @aanchal-sikka,
From what I understand, this issue seems related to the XMP metadata Adobe attaches to assets - specifically the version history stored under /jcr:content/metadata/xmpMM:History/*
.
One thing you might try is writing a Groovy script to clean up those history nodes. If this keeps happening, you could even set it up as a scheduled job using Sling Scheduler to handle cleanup automatically.
Here’s what could happen if we just ignore this:
-
The repository can get bloated over time, which might slow down overall performance.
-
Tar compaction could run into problems or cause stability issues during maintenance.
-
You might notice the DAM UI becoming sluggish, especially when loading asset properties for older or larger assets.
To avoid this going forward, a couple of ideas:
1. Limit over-versioning:
Check workflows like DAM Update Asset or any custom processes that might be appending too often to the history. Sometimes they trigger more than necessary.
2. Disable appending to history:
You could tweak the DAM Update Asset workflow by removing or modifying the XMP writeback step that adds to the history.
For automation, here are some options:
-
Start with a Groovy script for cleanup - try running it manually first to see the effect.
-
If the problem persists, set up a Sling Scheduler job to run the cleanup regularly.
-
Alternatively, add a workflow step to limit or clear xmpMM:History
as part of your metadata update process.
-
And in some cases, reviewing Dispatcher rules to prevent repeated uploads of the same asset might help too.
Santosh Sai

