[
https://issues.apache.org/jira/browse/FELIX-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glenn Marcy updated FELIX-3838:
-------------------------------
Attachment: felix-scr.89998-patch.txt
Attached is a patch with changes for two files:
1) BundleComponentActivator
The changes here are only to add LOG_DEBUG messages which were used to help
understand what was happening in the thread which would call enableComponents.
These were a help in tracking down the bug so wanted to make them available in
case they were helpful to others.
2) ImmediateComponentHolder
These changes contain a fix for the defect. The basic issue was that while
there were synchronized ( m_components ) blocks within the code, they were only
protecting access to that field at a very fine grained level. The changes
expand the scope of such blocks to account for the fact that changes to that
map also need to be consistent with changes to the m_enabled and
m_singleComponent fields as well.
> [DS] Race condition in ImmediateComponentHolder
> -----------------------------------------------
>
> Key: FELIX-3838
> URL: https://issues.apache.org/jira/browse/FELIX-3838
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.2
> Reporter: Glenn Marcy
> Attachments: felix-scr.89998-patch.txt
>
>
> There is a race condition where one thread is running the
> BundleComponentActivator
> and calling enableComponents on the ImmediateComponentHolder when another
> thread
> is running that has called configurationUpdated. The first thread is
> executing
> this:
> m_enabled = true;
> final ImmediateComponentManager[] cms = getComponentManagers( false );
> ...
> for ( ImmediateComponentManager cm : cms )
> {
> cm.enable( async );
> }
> The second thread is executing this:
> // enable the component if it is initially enabled
> if ( m_enabled && getComponentMetadata().isEnabled() )
> {
> newIcm.enable( false );
> ...
> }
> // store the component in the map
> putComponentManager( pid, newIcm );
> The failing sequence is this:
> The second thread executes the test of m_enabled and it is false, so it will
> not
> enable the component manager expecting that it will be enabled by
> enableComponents
> later when it is called. The first thread then sets m_enabled to true and
> gets a
> copy of the entries in the map of component managers in order to enable them.
> The
> second thread puts the component manager into that map, but after the first
> thread
> has already made a copy of the managers in that map, so the component manager
> the
> second thread created will not be enabled at all.
--
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
