Re: [equinox-dev] equinox ds
Hi Scott, Felix SCR guys already implemented some tasks related to RFC 190: https://issues.apache.org/jira/browse/FELIX-4403 https://issues.apache.org/jira/browse/FELIX-4769 https://issues.apache.org/jira/browse/FELIX-4405 https://issues.apache.org/jira/browse/FELIX-4391 Not done yet: https://issues.apache.org/jira/browse/FELIX-4401 I have played a bit with the version 2.0.0-SNAPSHOT a month ago, but looking the code today it seems that they returned to 1.8.3-SNAPSHOT. Will question them about that. regards, Cristiano On 19-02-2015 22:40, Scott Lewis wrote: On 2/19/2015 5:26 PM, BJ Hargrave wrote: See http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08088.html Thanks. I can't seem to find the SCR version at felix.apache.org that supports RFC190. Would you please point me in the right direction there? And given Thomas' plans for Mars (using Felix SCR version), how far along is the conversion work? Are the SCR bundle(s) going to be in Orbit at some point? Scott ___ 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
Re: [equinox-dev] equinox ds
On 2/19/2015 5:26 PM, BJ Hargrave wrote: See http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08088.html Thanks. I can't seem to find the SCR version at felix.apache.org that supports RFC190. Would you please point me in the right direction there? And given Thomas' plans for Mars (using Felix SCR version), how far along is the conversion work? Are the SCR bundle(s) going to be in Orbit at some point? Scott ___ 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
Re: [equinox-dev] Equinox DS Performance Problem
Thanks for opening the bug. For a while now I have been contemplating replacing the Equinox DS implementation with the Felix SCR/DS implementation for use in Equinox/Eclipse. There is no longer any active committers working on the Equinox SCR/DS implementation. I work closely with one of the lead committers of the Felix SCR/DS implementations (who happens to work for the same company as me). For that reason I don't have resources to spend on maintaining the Equinox SCR/DS implementation. Nobody else has step forward to take over the implementation of Equinox DS. For the Mars release I plan on moving the Felix implementation for Equinox/Eclipse. So this is a last request to the community. If you have interest, skills and time to contribute to the Equinox DS implementation let us know, otherwise I am moving forward with using the Felix SCR/DS implementation for Mars. Tom From: Colin Williams col...@i9technologies.com To: Equinox development mailing list equinox-dev@eclipse.org Date: 11/25/2014 06:46 PM Subject:Re: [equinox-dev] Equinox DS Performance Problem Sent by:equinox-dev-boun...@eclipse.org Done, thank you for the suggestion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453256 On Tue, Nov 25, 2014 at 3:56 PM, Alex Blewitt alex.blew...@gmail.com wrote: 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
Re: [equinox-dev] Equinox DS Performance Problem
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
Re: [equinox-dev] Equinox DS Performance Problem
Done, thank you for the suggestion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453256 On Tue, Nov 25, 2014 at 3:56 PM, Alex Blewitt alex.blew...@gmail.com wrote: 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 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options,
