It would be better to create a bug report at bugs.eclipse.org and attach the files and description there.
Alex Sent from my iPhat 6 > On 25 Nov 2014, at 21:26, Colin Williams <col...@i9technologies.com> wrote: > > 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> > _______________________________________________ > 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
_______________________________________________ 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
