jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergiy Shyrkov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3579) InternalVersionImpl.internalDetachPredecessor() and internalDetachSuccessor() do not check for duplicates when updating jcr:successors / jcr:predecessors
Date Tue, 23 Apr 2013 09:07:15 GMT

     [ https://issues.apache.org/jira/browse/JCR-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sergiy Shyrkov updated JCR-3579:
--------------------------------

    Attachment: screenshot-1.jpg
    
> 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.2.13, 2.4.3, 2.6
>            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

Mime
View raw message