You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2017/03/15 13:01:41 UTC
[jira] [Resolved] (JCR-4121) ConcurrentModificationException in
InternalVersionHistoryImpl.fixLegacy()
[ https://issues.apache.org/jira/browse/JCR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-4121.
-----------------------------------
Resolution: Fixed
Fixed in trunk: http://svn.apache.org/r1787043
> ConcurrentModificationException in InternalVersionHistoryImpl.fixLegacy()
> -------------------------------------------------------------------------
>
> Key: JCR-4121
> URL: https://issues.apache.org/jira/browse/JCR-4121
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4, 1.5, 1.6, 2.0, 2.1, 2.2, 2.4, 2.6, 2.8, 2.10, 2.12.0, 2.14
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
> Fix For: 2.15.2
>
> Attachments: JCR-4121.patch, JCR-4121-test-attempt.diff
>
>
> In some cases the method {{InternalVersionHistoryImpl.fixLegacy()}} may trigger a {{ConcurrentModificationException}}. The exception is caused by the iterator on the {{nameCache.keySet()}}. It only happens when the root version points to a successor version which has a same name sibling. In this case the {{legacyResolveSuccessors()}} will trigger a {{reload()}}, which in turn calls {{init()}} and then clears the {{nameCache}}. A version history does not actually allow same name sibling child nodes, but one of the repository instance I have access to does show this kind of structure.
> See also related issues JCR-3086 & JCR-1111.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)