Bundle startup becomes very slow with many bundles present
----------------------------------------------------------
Key: SLING-756
URL: https://issues.apache.org/jira/browse/SLING-756
Project: Sling
Issue Type: Bug
Components: JCR Install
Reporter: Bertrand Delacretaz
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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
