aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Reopened] (ARIES-1399) Trunk fails OSGi R6 CT
Date Thu, 24 Sep 2015 00:04:04 GMT


John Ross reopened ARIES-1399:

I'm reopening this because the chosen solution is not sufficient to address all possible scenarios.
Two of the three CT tests referenced in the description are failing again.


They are failing for a similar but not the same reason as before. This time, the INSTALLED
and RESOLVED events are both received but in the wrong order. The reason is that during the
synchronous processing of the INSTALLED event, the system repository gets called which retrieves
all capabilities for the bundle, including those for services, in order to cache them in the
capability set. This bypasses the protection of lazy computation previously added in order
to avoid having region digraph (which uses a bundle event hook) filter out the RESOLVED event.
All synchronous bundle listeners called after the system repository will see the RESOLVED
event before the INSTALLED event.

The second solution mentioned in the description is still an option. Another option would
be to use an asynchronous bundle listener for the system repository.

> Trunk fails OSGi R6 CT
> ----------------------
>                 Key: ARIES-1399
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>            Reporter: John Ross
>            Assignee: John Ross
>         Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, TEST-org.osgi.test.cases.subsystem-6.0.0.html
> The Subsystems implementation is currently failing three tests in the R6 CT as a result
of some of the recent performance tunings:
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationApplication
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1b_BundleIsolationFeatures
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationComposite
> It fails all three for the same reason. The tests explicitly install a bundle using the
region bundle context of the root subsystem. The bundle is subsequently started. Using a synchronous
bundle listener, the tests reasonably expect to see INSTALLED, RESOLVED, STARTING, and ACTIVE
bundle events. However, the RESOLVED event is missing. It is missing because:
> (1) The Bundle Event Hook, registered with a service ranking of Integer.MAX_VALUE, correctly
identifies the event as pertaining to an explicitly installed bundle and acts accordingly.
> (2) As normal, the bundle is wrapped by a Bundle Revision Resource in order to compute
the service capabilities and requirements if the Application Modeller service is present.
Previously, the capabilities and requirements were not cached but (lazily) computed with each
request. Today, they are computed once and cached at instantiation.
> (3) Computing the service capabilities and requirements requires searching for Blueprint
XML files through Bundle.findEntries which results in the framework attempting to resolve
the bundle.
> (4) Region Digraph, through its own bundle event hook, receives the RESOLVED event before
the INSTALLED event. Because this is an unknown bundle, the event is filtered and not delivered
to any listeners, synchronous or otherwise.
> There are at least a few possible solutions to the problem.
> (1) Have the Bundle Event Hook explicitly add the bundle to the region using Region.addBundle(Bundle)
as part of handling the INSTALLED event. This would (+) solve the immediate issue but (-)
promote out of order event delivery to other hooks and listeners.
> (2) Prevent bundles under these circumstances from resolving altogether. This would (+)
solve the immediate issue and (+) prevent out of order event delivery, but (-) eliminate the
possibility of searching fragment bundles for Blueprint XML files. 
> (3) Lazily compute service dependencies and requirements in Bundle Revision Resource
as before but still cache them. This would (+) solve the immediate issue, (+) resemble how
things already were before performance tuning, (+) not contribute to out of order event delivery,
and (+) leave open the possibility of searching fragments for Blueprint XML files.

This message was sent by Atlassian JIRA

View raw message