Community
Participate
Working Groups
Build Identifier: Equinox resolver uses heuristic meachanisms to reduce the number of possible solutions when trying to resolve a set of bundles. As a consequence, sometimes resolution fails because some of the valid solutions are discarded. Although this reduction is important to prevent endless resolution, there are cases when it could be useful to be able to configure resolver's timout/treshold values. An example here is a relatively small set of bundles as each has many imports and exports. This increases the number of the possible solutions. On top, the presence of uses clauses decreases the number of valid solutions and these few solutions are often discarded on the way. What is the best way to tweak the resolver? Reproducible: Sometimes
I have spent some time investing this issue - see mailing list communication:http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg06968.html . I saw that there are currently limits on both count and time. The count limit is for the total number of imports, require and generic require constraints with multiple suppliers. This maximal limit is hard coded and could not be configured. A heuristic is used to reduce the number of the constraints with multiple suppliers. The time limit is used when searching the best possible combination of bundles, satisfying the uses constraints. This takes place after the reduction of the constraints with multiple suppliers. This timeout could be configured through the property osgi.usesTimeout. One way could be to introduce a property, with which to also the number of constraints with multiple suppliers. The user could configure in this way a larger number, which could lead to resolving endlessly - but at least will give the user a chance to get a solution, even for a more time. Another way is to try to modify the heuristic, but this is maybe worse than configuring, because a new heuristic probably could solve a particular case, which now is problematic, but may fail for other scenarios, for which the current heuristic works fine.
(In reply to comment #1) > Another way is to try to modify the heuristic, but this is maybe worse than > configuring, because a new heuristic probably could solve a particular case, > which now is problematic, but may fail for other scenarios, for which the > current heuristic works fine. For a first step I think we should add the ability to configure the time-out and the max limit on constraints with multiple suppliers. I suggest a value of 0 to be used to specify infinite limits. Lazar, are you interested in providing a patch for this?
(In reply to comment #2) > (In reply to comment #1) > > Another way is to try to modify the heuristic, but this is maybe worse than > > configuring, because a new heuristic probably could solve a particular case, > > which now is problematic, but may fail for other scenarios, for which the > > current heuristic works fine. > > For a first step I think we should add the ability to configure the time-out > and the max limit on constraints with multiple suppliers. I suggest a value of > 0 to be used to specify infinite limits. Lazar, are you interested in > providing a patch for this? Yes, I will provide a patch for this. Only one thing - the timeout is already made configurable through the property osgi.usesTimeout. So I will add another property for configuring the limit for the number of constraints with multiple suppliers.
Created attachment 204943 [details] Proposed patch to add an option for configuring the max number of constraints with multiple suppliers This patch adds a property osgi.usesLimit. Through this property the max number of constraints with multiple suppliers could be configured. This is taken into account when resolving uses constraints. There is a default value for this number and it is 10. This value is used if the property is not set, or if it is set with invalid or negative value. If the property is set to zero, Integer.MAX_VALUE is used as max count. If the property is set to a positive value, this value is used as the max count. A property for configuring the timeout for uses constraint resolution already exists and i did not change this logic.
Thanks Lazar, I will look at the patch.
I released a modified fix with the commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=89de09e1b109112f63a804161e896ecb2facf439 Lazar, I had to change your fix to have proper defaults. There were cases where if the properties were not specified then the timeouts and the max for multiple suppliers was not working as expected.
(In reply to comment #6) > I released a modified fix with the commit: > > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=89de09e1b109112f63a804161e896ecb2facf439 > > Lazar, I had to change your fix to have proper defaults. There were cases > where if the properties were not specified then the timeouts and the max for > multiple suppliers was not working as expected. Thanks!
Created attachment 205717 [details] Doc patch for osgi.usesTimeout and osgi.usesLimit properties This patch documents the two properties - the existing osgi.usesTimeout and the newly introduced osgi.usesLimit
