[jira] [Updated] (JCR-4121) ConcurrentModificationException in InternalVersionHistoryImpl.fixLegacy()
[
https://issues.apache.org/jira/browse/JCR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-4121:
Fix Version/s: 2.16
> 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.16, 2.12.7, 2.14.1, 2.10.6, 2.4.8, 2.6.9, 2.8.6, 2.15.2
>
> Attachments: JCR-4121-test-attempt.diff, JCR-4121.patch
>
>
> 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-.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (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 updated JCR-4121:
--
Fix Version/s: 2.8.6
2.6.9
2.4.8
2.10.6
2.14.1
2.12.7
Merged into branches:
- 2.14: http://svn.apache.org/r1787054
- 2.12: http://svn.apache.org/r1787055
- 2.10: http://svn.apache.org/r1787059
- 2.8: http://svn.apache.org/r1787063
- 2.6: http://svn.apache.org/r1787080
- 2.4: http://svn.apache.org/r1787081
> 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.12.7, 2.14.1, 2.10.6, 2.4.8, 2.6.9, 2.8.6, 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-.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (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 updated JCR-4121:
--
Attachment: JCR-4121.patch
Attached proposed changes [^JCR-4121.patch].
[~reschke], WDYT?
> 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-.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (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 updated JCR-4121:
--
Description:
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-.
was:
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 is missing. In this case the
{{legacyResolveSuccessors()}} will trigger a {{reload()}}, which in turn calls
{{init()}} and then clears the {{nameCache}}.
See also related issues JCR-3086 & JCR-.
> 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-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-.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (JCR-4121) ConcurrentModificationException in InternalVersionHistoryImpl.fixLegacy()
[
https://issues.apache.org/jira/browse/JCR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-4121:
Attachment: JCR-4121-test-attempt.diff
I attempted to reproduce the exception (see attachment), but haven't suceeded
yet.
(I get a *different* exception, though)
> 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-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 is missing. In this case the
> {{legacyResolveSuccessors()}} will trigger a {{reload()}}, which in turn
> calls {{init()}} and then clears the {{nameCache}}.
> See also related issues JCR-3086 & JCR-.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
