Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.

VersionManager purging seems to have no effect

Avatar

Level 2

I am running Version purge as described in the docs https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/version-purging....

 

with settings of

versionpurge.paths = /content

versionpurge.recursive = true

versionpurge.maxVersions = 0

versionpurge.minVersions = 0

versionpurge.maxAgeDays = 1

 

to my understanding, this should delete all versions that are older than 1 day, in other words: only versions from yesterday are kept, anything else is gone.

 

Hoewever if I check my pages, I still see the same number of pages with the properties

jcr:baseVersion

jcr:versionHistory

jcr:predecessors

e.g. when I run this query, the number of results is the same

http://localhost:4502/bin/querybuilder.json?type=cq%3aPage&p.hits=selective&p.properties=jcr:path jcr:content/jcr:predecessors&p.offset=0&p.limit=1000&path=/content&property=jcr:content/jcr:predecessors&property.operation=exists&property.value=true

 

My assumption was that if all versions of a page are purged, the above-mentioned properties would be gone (as there should be no predecessors anymore).

 

When I use the purge tool of the classic UI /etc/versioning/purge.html for debugging, as suggested in the docs, I am seeing messages like this in the log output

A12 ABC /content/site/en/sustainability/abc/jcr:content
retained  V 1.1* Thu May 27 2021 14:12:17 GMT+0000

 

B14 XYZ /content/site/en/sustainability/xyz/jcr:content
retained  V 1.15* Tue Nov 02 2021 15:06:07 GMT+0000

 

 CC template /content/site/en/spotlight/template/jcr:content
retained  V 1.0* Fri Oct 16 2020 14:47:48 GMT+0000


These dates are clearly much older than my given threshold, yet they are not deleted.

When I check my error log, I see a lot of messages like

com.day.cq.wcm.core.impl.VersionPurgeTask Purged version 1.2 of /content/site/...

but the paths mentioned above are not among them (kind of makes sense if they are not purged).

 

What am I missing?
Also, assuming I want to purge ALL versions, e.g. on a lower test environment where I have no need for them, how can I best achieve that?

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

3 Replies

Avatar

Community Advisor

Hi, 

As per the  documentaion if the max versions value is less then 1 then purging is not based on the number of versions.  So having value as 0 may be creating some conflicts and keeping the versions.

 

  • versionmanager.maxNumberVersions (int, default 5)
    On version purge, any version older than the n-th newest version will be removed. If the value is less than 1, purging is not performed based on the number of versions.

I have done a random testing by creating below configuration and looks like the versions are getting purged and only 1 latest version is kept after purging.  I feel atleast 1 version will be available. Play around with the configuration and let us know your findings on the same.

 

versiionPurge.JPG

Thanks,

Somen

Avatar

Level 2

Yes, for values higher than zero the docs make sense and I understand what it does.

But I am trying to delete ALL versions, completely and immediately. As far as I can see, this is not possible with the builtin VersionPurge tool, and the documentation is unclear on what the behaviour is when both maxVersions and maxAgeDays are zero.

 

The best way is to set maxAgeDays to 1 and all other values to 0, then it should remove all versions but only after two days.

 

I have also discovered that there are additional issues with the versioning or at least the VersionPurge tool.

If there are two AEM Author instances, call them X and Z, and Z has a page with versions, and X has the same page (path) with versions

and a package is created with that page on X, uploaded to Z and installed - then there seems to be a potential for hickups in the versions that VersionPurge is not able to clean up.

 

Specifically: a package that includes a versioned page, then that page will have the jcr:uuid and mixinTypes = mix:versionable properties in the .content.xml file (package will not include older version as those are in /jcr:system/jcr:versionStorage which is not part of the package obviously).

But on the target system (with different versions for that page), AEM will repair/restore the jcr:baseVersion, jcr:versionHistory and jcr:predecessors properties which are not part of the package content.xml file.

 

In principle this makes sense, as that should set the version history of that page on the target machine - and should be consistent if successful.

 

But I can see that VersionPurge is struggling with some nodes that keep showing up in the logs, so at some point in time something was mixed up presumably due to content packages and duplicate uuids and now there is an inconsistency, either in the properties, and/or jcr:versionStorage and/or in the versionstore index (/oak:index/versionStoreIndex)

 

So the really interesting question is: how can the Version Storage and index be reset completely, in a clean way?

 

Avatar

Level 2

This post also shows a similar issue:

https://stackoverflow.com/questions/66607859/removing-versions-from-versionstorage-for-deleted-pages... 

Basically the version storage has "orphaned" versions of deleted pages, because the pages no longer exist. The out-of-the-box VersionPurge does not clean those either.

 

The local versions can easily be checked with
http://localhost:4502/bin/querybuilder.json?type=nt%3aversionHistory&p.hits=selective&p.properties=j... 
it will quickly show a lot of stuff that should no longer be there