[
https://issues.apache.org/jira/browse/FELIX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530737
]
Karl Pauls commented on FELIX-381:
----------------------------------
As far as I can see that might be true. There is a race condition between
checking whether a module is already resolved and actually getting the lock to
resolve it -- hence, there should be the possibility to resolve it twice. It
might be enough to move the isResolved check inside the synchronized block.
> Started bundles may change state to RESOLVED
> --------------------------------------------
>
> Key: FELIX-381
> URL: https://issues.apache.org/jira/browse/FELIX-381
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: 1.0.0
> Reporter: Felix Meschberger
> Attachments: FELIX-381.patch
>
>
> In certain situations a bundle, which has already been started gets its state
> changed back to RESOLVED.
> Consider the following situation: A thread T1 is starting a Bundle A while
> another thread T2 is starting a Bundle B depending on Bundle A. T2 resolves
> Bundle B and as T1 has not done it yet assumes to have to resolve Bundle A.
> Before T2 can resolve Bundle A, T1 resolves Bundle A itself and actually
> starts Bundle A at the end setting the state to ACTIVE. Then T2 finishes
> resolving and calls the ResolveListener to inform that Bundle A has been
> resolved, which causes the state of Bundle A to be set to RESOLVED.
> The consequence is that Bundle A has been started - BundleActivator called,
> STARTED event fired - and then its state is just set to RESOLVED and a
> RESOLVED event is fired. This is incorrect as (1) Bundle A has already
> started and before entering the RESOLVED state (again) it would have to be
> stopped and (2) getting A back into resolved state would cause STOPPING and
> STOPPED events to be fired and not a RESOLVED event.
> The fix would probably be to ignore the moduleResolved event for bundles,
> which are not in the INSTALLED state.
> Testing this issue is difficult as it heavily depends on timing and
> environmental issues, yet we have a setup, which produces the situation
> relatively often times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
