[jira] [Comment Edited] (FELIX-3807) Refreshing bundles should first grab all the bundle locks to avoid concurrent modifications of those bundles

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531035#comment-13531035 ] 

Guillaume Nodet edited comment on FELIX-3807 at 12/13/12 2:40 PM:
------------------------------------------------------------------

I think there is still a potential problem.
Let's consider a resolved bundle and two threads, one doing a refresh and one starting the bundle.
The first thread can grab the global lock and will try to stop all the dependant bundles, including the one we consider (this operation will do nothing).
Just after that, and before the thread refreshes the bundle, the second thread start the bundle.  It can grab the bundle lock which has been freed by the first thread and does not need to grab the global lock because the bundle is already resolved.  That thread then start the bundle.  When the first thread tries to refresh the bundle, the bundle will be in an invalid state and the operation will lead to an inconsistent state.

I'm currently investigating an NPE in Resolver#calculatepackageSpace and found a weird state which lead me to the above analysis.  I think it's related as I ended up with a NPE on a bundle which is already resolved while being in the refresh list being processed (and that's during the first bundle restart, so it does not come from a previous resolution).

                
      was (Author: gnt):
    I think there is still a potential problem.
Let's consider a resolved bundle and two threads, one doing a refresh and one starting the bundle.
The first thread can grab the global lock and will try to stop all the dependant bundles, including the one we consider (this operation will do nothing).
Just after that, and before the thread refreshes the bundle, the second thread start the bundle.  It can grab the bundle lock which has been freed by the first thread and does not need to grab the global lock because the bundle is already resolved.  That thread then start the bundle.  When the first thread tries to refresh the bundle, the bundle will be in an invalid state and the operation will lead to an inconsistent state.

I'm currently investigating an NPE in Resolver#calculatepackageSpace and found a weird state which lead me to the above analysis (not sure if it's related at all yet though).
                  
> Refreshing bundles should first grab all the bundle locks to avoid concurrent modifications of those bundles
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-3807
>                 URL: https://issues.apache.org/jira/browse/FELIX-3807
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>            Reporter: Guillaume Nodet
>
> This will avoid possible problems where bundles states can change between stopping the bundle and actually refreshing them.

--
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