[
https://issues.apache.org/jira/browse/FELIX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-381.
-----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I have just committed a fix for this, which basically implemented Karl's
suggestion of moving the isResolved() check inside the synchronized block. I
also tried to simplify the locking protocol by removing the locks on "this"
from the isResolved/setResolved methods, making them private, and adding a note
that they should only be called when holding a lock on m_factory.
I also added a warning if you see a resolved event for a bundle that is not in
the INSTALLED state so that we can more easily see when this occurs in the
future.
Felix, do your best to see if this patch resolves the issue. If so, please
close it.
> 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
> Assignee: Richard S. Hall
> 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.
