Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
When running the jcrinstall integration tests with a few hundreds of very simple bundles, the bundle.start call in the BundleResourceProcessor class becomes very slow. With a few bundles it takes only a few milliseconds, and goes up to the 500 msec range with about 500 installed bundles.
Seems like most of that time is spent in the Felix R4SearchPolicyCore.resolve() method, but I haven't investigated that in detail yet.
To reproduce, run "mvn clean install" in extensions/jcrinstall/testing, with these parameters:
-D sling.test.scale.factor = 20
-D sling.test.bundles.wait.seconds = 200
With these values, the StopAndChangeBundlesTest installs 140 bundles by copying them into the repository, disables jcrinstall, replaces the bundles with 260 new ones and reactivates jcrinstall.
When reactivated, jcrinstall uninistalls the 140 bundles and then installs and starts the 260 new ones - this is when the bundle.start becomes very slow.
All bundles are clones of the extensions/jcrinstall/testbundles/observer bundle, same code but unique bundle symbolic name and name. This causes warnings from the Felix framework as all bundle clones contain a component with the same name. I don't think that's related to the long start time though.
As it seems like the problem has to do with resolving the bundle, here are the package exports/imports of the test bundle:
exports: none
imports:
javax.jcr,version=1.0.0 from org.apache.sling.jcr.api (16)
javax.jcr.observation,version=1.0.0 from org.apache.sling.jcr.api (16)
org.apache.sling.jcr.api,version=2.0.3.incubator-SNAPSHOT from org.apache.sling.jcr.api (16)
org.osgi.framework,version=1.4.0 from System Bundle (0)
org.osgi.service.component,version=1.0.0 from System Bundle (0)
org.slf4j,version=1.5.2 from org.apache.sling.commons.log (19)