[jira] [Updated] (FELIX-3838) [DS] Race condition in ImmediateComponentHolder

["Glenn Marcy (JIRA)" <ji...@apache.org>]

     [ 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