felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-4000) [DS] ConcurrentModificationException in AbstractComponentManager iterating through m_dependencyManagers
Date Wed, 27 Mar 2013 19:21:15 GMT
David Jencks created FELIX-4000:

             Summary: [DS] ConcurrentModificationException in AbstractComponentManager iterating
through m_dependencyManagers
                 Key: FELIX-4000
                 URL: https://issues.apache.org/jira/browse/FELIX-4000
             Project: Felix
          Issue Type: Bug
          Components: Declarative Services (SCR)
    Affects Versions: scr-1.8.0
            Reporter: David Jencks
            Assignee: David Jencks
             Fix For: scr-1.8.0

	at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
	at java.util.AbstractList$Itr.next(AbstractList.java:343)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.updateTargets(AbstractComponentManager.java:1002)
	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:580)
	at org.apache.felix.scr.impl.config.ImmediateComponentHolder.configurationDeleted(ImmediateComponentHolder.java:249)
	at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:232)

m_dependencyManagers is initialized in the constructor and the only other place it changes
is in clear() where it's cleared.  My first idea is to just not try to help the GC and not
actually clear the m_dependencyManagers list.  Otherwise we'll have to add a lot of locking
to make sure that no threads disable the component while any other thread is doing anything.

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

View raw message