You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2009/08/11 13:56:15 UTC

[jira] Closed: (SLING-756) Bundle startup becomes very slow with many bundles present

     [ https://issues.apache.org/jira/browse/SLING-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz closed SLING-756.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: JCR Install 2.0.4

Fixed as part of SLING-904

> 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
>             Fix For: JCR Install 2.0.4
>
>         Attachments: SLING-756-graph.sh
>
>
> 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.