Additional testcase that show some unexpected behavior of resolver #469
Conversation
laeubi
force-pushed
the
complex_test_case
branch
from
4112c54 to
9ec0b67
Compare
|
I now was able to derive a "public" test set it shows the following: If you run the org.eclipse.osgi.tests.container.TestModuleContainer.testManyBundles() test you will see that at first round it runs forever (you can increase the timeout if you like) it then fails like: then the second round is fast and results in Plotting the calls and number of the method one can see here that |
|
How can one make this finally resolve is to replace the file then it still takes some times but resolve in the first round (but still feels too slow) and now the chart looks like this:
|
laeubi
force-pushed
the
complex_test_case
branch
from
9ec0b67 to
4cbe2b7
Compare
|
I now have created a different test set where one can see complexity explosion:
Test finishes for me in 0.087 seconds with 15 iterations and 51 unprocessed permutations
please note that this bundle is rather only a consumer of things not really used by anyone, so it should be easy to resolve, but test now takes 2.8 seconds (32 times longer) and finishes with 3500 unprocessed permutations and 2000 iterations (133 times more iterations)
|
laeubi
force-pushed
the
complex_test_case
branch
from
4cbe2b7 to
a5a434d
Compare
|
I have now made some experiments and came up with the This itself does not solve the problem and is maybe not complete but I still think its worth to share it here as something to discuss, this currently strikes out for example some of the |
laeubi
force-pushed
the
complex_test_case
branch
2 times, most recently
from
e161e88 to
3f7f9d4
Compare
I did this now and it strikes out one more candidate of a substitution package ( |
|
Next problem is now this kind of violations: as one can see it looks like in the substitution step only one of the packages are substituted in a permutation but the uses is not taken into account. |
laeubi
force-pushed
the
complex_test_case
branch
from
3f7f9d4 to
8bcd62a
Compare
|
I now added a new step that when a permutation is computed it checks if the removed capability has any What next needs to be checked that after this first filter steps there can be any providers for an import left that now conflicts with the available choices for their use clauses. An example is this what lists all requirements that currently has more than one choice for the bundle: as one can see |
|
After striking substitution packages out now still a lot of use constraint violations happen making the resolving explode: the elk layered starts with this alternatives: while xbase.lib has no alternatives at all but using a reexport of guava: looking at this one can see that any bundle that requires |
laeubi
force-pushed
the
complex_test_case
branch
from
8bcd62a to
f41e8ef
Compare
Currently candidates of a substitution package might be permuted even though they are mandatory for others (e.g. they import a package that can only be fulfilled by this one capability). This now adds a ProblemReduction class that tries to figure out some conflicting options and remove them from the set of items to consider.
laeubi
force-pushed
the
complex_test_case
branch
from
f41e8ef to
b02fd1c
Compare
|
After filtering the reexport inconsistency now we have this use constraint violation: Looking at the initial state the devhelp itself has no alternatives:
So in this case This will probably be challenging to solve but we finally now reached the point to the root error that is reported in this test-case ( because the resolver can not really "blame" the system bundle ( Here is a chart of the current state and as one can see at laest the usesPermutations have already dropped below the initial threshold of about 1000 to 500 now:
|
|
Just for testing I added a preliminary check that if the "system bundle" is a provider for a package strike out all other providers as an alternative for that, then the mentioned line is never hit and the resolver completes after 13 seconds with 272 iterations successfully with this search graph:
as one can see uses permutations drop below 100 now (import permutations still growing) |
this is not to meant to be merged in its current form
The added testcase demonstrates some unexpected behavior of resolver we have already seen in the past eclipse simrel releases and I see regular with custom installations, also m2e suffers from long running resolve operations when starting test from the IDE.
To summarize the both things that hurt the most here are boil down to the following facts:
Undesired substitutions
V1.0has a substitution packageAand imports it with consumer range (e.g.[1,2)) and export it with a specific version1.0V1.5that exports the packageAwith version1.5exporting the package with version1.5CimportingAwith range[1,2)PimportingAwith range[1,1.5)Under some circumstance now it happens that the package of bundle
V1.0get substituted with these fromV1.5resulting inPnot being resolved because the import package can not be resolved anymore.What is expected: the resolver does not substitute the package for
V1.0because that will make it impossible forPto resolve.FYI @tjwatson in the bundle test set I can provide to you this is the
org.eclipse.lsp4j.jsonrpcbundle that gets packages substitutedUndesired binding to a higher package version causing use-constraint violations
Aimporting a package with a consumer range (e.g.[1,2))Bimporting a package with a narrow range (e.g.[1,1.5))BrequiresA.Under some circumstances it now happens that
Ais bound to a higher version (1.8) andBis failed to resolve because there is a use constraint violation becauseBis exposed to the same package in different versions, the bundleAis actually not used by any other bundle at all.What is expected: the resolver does not bind
Ato a higher version if a consumer ofArestrict it to a lower version already as it makes any consumer ofAexposed to use-constraint violations.@tjwatson in the bundle test set I can provide to you this is the
org.eclipse.sprotty.serverbundle that gets packagescom.google.gson;version="[2.8,3)"bound to a higher gson version than those bundles that requireorg.eclipse.sprotty.serverWhat we have done in the past
In simrel or similar situation we are currently forced to a very unfortunate situation that people (mostly @merks ) are forced to watch the dependencies and carefully examine the dependencies, asking projects to update their dependencies to "fix" such issues. While it is a lot of effort this has been working in the past but puts a lot of stress on the release process.
For plugin providers / product vendors this always leads to the very unfortunate situation that they are having hard times to update their products / plugins and still maintain a certain degree of backward compatibility with older eclipse releases or users that are at the bleeding edge. The main problem is that in almost all cases it is impossible to provide a "reproducing testcase" for the following reasons:
Why this is undesired behavior
The OSGi resolver is actually the entity that should solve complex dependency problems, it should not be the developer or release manager that needs to find out how to resolve the requirements best.
Even worse, in the case I have analyzed in deep here I can actually make the state resolve when I perform some manual steps, these steps are rather trivial operations (if one gets the idea) but the resolver burns a lot of CPU cycles and does not find a suitable solution and simply gave up after a timeout or even there are situations where it seem to run forever (> 30 minutes until I killed the process).
This can be especially frustrating if one looks at the "unsatisfied" requirements and see they are there, or has use-violations but can "see" the solution that must be chosen... a computer should even be better to spot such things
The "algorithm" to fix the resolve problem is implemented here:
but it has the drawback that it takes a considerable amount of time and there is no guarantee it always fixes the problem as it simply has no way to perform anything more than ask the resolver to try a little bit harder on something that seems to be part of the problem.
@tjwatson I'll contact you directly with how you can get the bundle test set in the hope that is helps, the test-case here actually resembles the problem quite good, it shows in first round a timeout after two minutes, then some bundles are selected for refresh, this again times out but with a different set of bundles, repeating this then leads with two more refreshes to a resolved state. It even seem not be much important how high the timeout is so basically a lot of time is spend here without making any progress.