jcr:content/metadata/xmpMM:History More than 1000 child nodes

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.