[
https://issues.apache.org/jira/browse/FELIX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-381:
------------------------------------
Description:
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.
was:
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.
> 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.
