sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bosschaert (JIRA)" <>
Subject [jira] [Commented] (SLING-6831) ConcurrentModificationException in OSGi Installer
Date Fri, 05 May 2017 09:18:04 GMT


David Bosschaert commented on SLING-6831:

Hi [~cziegeler], thanks for looking into it.

I think the problem is that {{getEntityIds()}} returns the valueset that is backed by the
same object to the client (in this case the OSGiInstallerImpl). That client will iterate over
that set outside of synchronization. Then at the same time some other code might modify the
collection, but whether or not that's synchronized doesn't have an effect on the client as
it doesn't do the synchronization.

Maybe another option might be to return a copy to the client in {{getEntityIds()}}? 

> ConcurrentModificationException in OSGi Installer
> -------------------------------------------------
>                 Key: SLING-6831
>                 URL:
>             Project: Sling
>          Issue Type: Bug
>          Components: Installer
>    Affects Versions: Installer Core 3.8.6
>            Reporter: David Bosschaert
>            Assignee: Carsten Ziegeler
>             Fix For: Installer Core 3.8.8
>         Attachments: SLING-6831.patch
> Under certain scenarios I'm getting: 
> {code}java.util.ConcurrentModificationException: null
> 	at java.util.HashMap$HashIterator.nextNode(
> 	at java.util.HashMap$
> 	at
> ...{code}
> To me this seems caused by the fact that the Map datastructure in the PersistentResourceList
is non-concurrent.
> PersistentResourceList.getEntityIds() returns the map's values directly. This is what
is used in OsgiInstallerImpl line 1390:
> {code}
>     public Collection<String> getEntityIds() {
>         return;
>     }{code}
> And the client code iterates over that, causing the exception.

This message was sent by Atlassian JIRA

View raw message