Sergiy Shyrkov created JCR-3579:
-----------------------------------
Summary: InternalVersionImpl.internalDetachPredecessor() and
internalDetachSuccessor() do not check for duplicates when updating
jcr:successors / jcr:predecessors
Key: JCR-3579
URL: https://issues.apache.org/jira/browse/JCR-3579
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: versioning
Affects Versions: 2.6, 2.4.3, 2.2.13
Reporter: Sergiy Shyrkov
Attachments: screenshot-1.jpg
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
