[
https://issues.apache.org/jira/browse/FELIX-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-5528.
-------------------------------
Resolution: Fixed
I committed support for this in r1782457.
The main idea is that we now wait for STARTING and STOPPING bundles and when we
get the lock we check if they are not STARTING or STOPPING. If they are not we
are good and otherwise, we had the bundle lock already - hence, we are in a
cycle and throw the exception we previously always did throw directly when the
bundle was STARTING or STOPPING.
> Improve handing of bundle updates concurrent to other lifecycle changes
> -----------------------------------------------------------------------
>
> Key: FELIX-5528
> URL: https://issues.apache.org/jira/browse/FELIX-5528
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: framework-5.6.1
> Reporter: Karl Pauls
> Assignee: Karl Pauls
> Fix For: framework-5.6.2
>
>
> Updating a bundle that is in the STARTING or STOPPING state is currently
> causing a bundle exception saying that we couldn't perform the update.
> According to the current spec we have to allow to call update on bundles in
> the STARTING or STOPPING state and handle them like we would handle ACTIVE
> bundles (I.e., wait until the bundle is in the ACTIVE state and then stop it)
> or wait until the bundle is RESOLVED, respectively, and then do the update.
> The reason, I believe, we currently throw the exception is that we have to
> prevent the case where a bundle that is getting STARTED or STOPPED triggers
> an update of itself (directly or indirectly) in the same thread before it has
> transitioned into RESOLVED or ACTIVE. If that happens, we'd otherwise run
> into a deadlock which might even involve the global lock (and hence, pretty
> much deadlock the complete framework).
> However, we should be able to detect that case separately and only then throw
> an exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
