Hi everyone, This is a follow-up to my forum post [1], because I have more information now and firmly believe this is a problem with Equinox, and not my code. I have a simplified test case that duplicates the problem [2], and have verified that Felix does not exhibit the same behavior.
When firing up a new instance of a Declarative Services component, either a regular component or a newInstance of a ComponentFactory, Equinox checks for dependency cycles ([3] and [4], for regular components and component factory instances, respectively). Unfortunately, it does this by walking the entire list of components and factory instances to check for dependencies, and then walking the entire dependency graph to check for cycles (see [5] and [6]). After checking for cycles, it then walks the entire list again [7] to check for components that may need to be disabled based on the new dependency graph. Now, I'm not sure why the dependency cycle checking is necessary when activating a new factory instance, since presumably it would have been checked when the component was resolved or at least the first time an instance of that factory was created. Even if it is necessary every time, though, wouldn't it only be necessary to check the portion of the dependency graph that is reachable from the new instance, rather than the entire dependency graph of all enabled components? And then furthermore, wouldn't it only be necessary to check the same list of potentially affected components for ones that need to be disabled, rather than all of them? As a result of this, Equinox exhibits O(n^2) runtime in activating new components or creating new instances of factory components, based on the number of components in the runtime and the complexity of the dependency graph. In my test case [2], a fairly simple dependency graph (B->C->D), which is then referenced by 3000 factory instances (A->B), takes minutes to start because of this (see [9]). Adding this bundle to a Felix container results in Felix starting the bundle and all 3000 factories instantly. I will say that I'm not particularly familiar with the Equinox internals, but I have added timing information into a local copy of the DS project, and can verify that findDependencyCycles and resolveEligible both take an excessive amount of time, proportionate to the number of total components in the system. I'm also not very familiar with the Felix internals, but I can't see that Felix does any dependency cycle checking when creating a new factory instance ([8]). I hope this was detailed enough to explain the problem I'm experiencing. Can anyone verify that this is an issue, or explain why it needs to be done? Or offer workaround suggestions to allow us to still use DS ComponentFactories with more than a few hundred services/factories? Thanks, --Colin [1] - https://www.eclipse.org/forums/index.php/t/868856/ [2] - Attached [3] - http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n476 [4] - http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1042 [5] - http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1073 [6] - http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1140 [7] - http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n511 [8] - https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java#L120 [9] - http://pastebin.com/CNrHFE8C [10] - http://pastebin.com/mb3AbP2S
com.i9technologies.equinoxtest_1.0.0.201411251422.jar
Description: application/java-archive
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
