Community
Participate
Working Groups
There have been a number of performance improvements to the felix resolver that we need to pick up in the Neon release. https://issues.apache.org/jira/browse/FELIX-4656 It is too late in the Mars release to consider picking this up.
See bug 460393 for a scenario that exercises the performance of the resolver.
(In reply to Thomas Watson from comment #0) > There have been a number of performance improvements to the felix resolver > that we need to pick up in the Neon release. > > https://issues.apache.org/jira/browse/FELIX-4656 > > It is too late in the Mars release to consider picking this up. I've done much more review on the changes to the felix resolver. I think it would be best to attempt to get this in now for Mars M7. I have some suggested superficial changes to the code to make it more understandable. For now I am releasing the current version of the code fix.
Latest released with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=1a8689effb7e188e7a8fc2af1c1df95c5afb55b8 Leaving bug open for the additional changes I suggested in the felix bug.
Hello Thomas, I am the same person that commented yesterday on the Felix-4656 issue and who had to patch WebSphere Liberty to be able to start a large application. You linked bug #460393 and, if I understood correctly, a possible work-around for that problem is to set equinox.resolver.revision.batch.size=1 I'd like to understand if in your opinion that configuration property may also resolve the issue I am experiencing with WebSphere Liberty as I would prefer to specify a custom property as an interim fix rather than having to patch a JAR in the server installation folder.
(In reply to GianMaria Romanato from comment #4) > Hello Thomas, > > I am the same person that commented yesterday on the Felix-4656 issue and > who had to patch WebSphere Liberty to be able to start a large application. > > You linked bug #460393 and, if I understood correctly, a possible > work-around for that problem is to set > > equinox.resolver.revision.batch.size=1 > > I'd like to understand if in your opinion that configuration property may > also resolve the issue I am experiencing with WebSphere Liberty as I would > prefer to specify a custom property as an interim fix rather than having to > patch a JAR in the server installation folder. I doubt that property will help fix your issue. I suspect your issue is in the usage of the Resolver service implementation by Aries subsystems when resolving a Subsystem at install time. The equinox.resolver.revision.batch.size property controls the batch size for bundle resolution at the framework runtime level. This configuration property only got introduced in Mars to allow configurations to increase the batch size if they wanted to. In Luna (the version currently used by liberty) the batch size is hard coded to 1 already. So unfortunately this configuration will not help you for subsystem resolution.
Thank you very much for your answer, this probably saved me half a day of useless testing.
Updated with the latest after applying my patch from the felix bug to use the term delta: https://issues.apache.org/jira/browse/FELIX-4656 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=f12173bac6175be732dfe42dc8ffb45ccbf68652
