Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.2.13, 2.4.3, 2.6
-
None
-
None
Description
We are using Jackrabbit 2.2.x branch (although the issue seems the same with 2.4.x and 2.6 so far I see).
We have a maintenance job that runs periodically and purges the old unused versions of nodes to keep the versioning store and index in boundaries.
The Job is using Jackrabbit Versioning API to remove versions.
The org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.removeVersion(Name) has the call to detaching the removed version from the version graph:
// detach from the version graph
v.internalDetach();
which in turn calls InternalVersionImpl.internalDetachPredecessor() and internalDetachSuccessor() methods to update predecessors and successor.
Those two methods are using List to calculate new values and store them in corresponding jcr:successors or jcr:predecessors properties.
The only thing is there is no check for duplicates in those lists, so with the time we see that jcr:successors and jcr:predecessors have duplicates (and they are growing with each version removal 
). See attached screenshot.
From my feeling the internalDetachPredecessor() and internalDetachSuccessor() should rather use HashSet (or if the order is important a LinkedHashSet) instead of List to prevent storing duplicates.
