felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-381) Started bundles may change state to RESOLVED
Date Thu, 27 Sep 2007 14:18:50 GMT

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

View raw message