One potential solution is for the resolver immediately deliver some warnings with a bit of trace details when it realizes that the computation is exceeding normal levels of complexity.
- Ray On Sat, Nov 3, 2018, 11:45 Raymond Auge <raymond.a...@liferay.com wrote: > It would be useful to make this scenario produce a louder perhaps more > obvious error message. > > If you could maybe create an issue for improvement on Apache Felix JIRA, > under Resolver project with as many details as you could provide maybe we > can do something. > > These rare and complex scenarios don't have to be so time consuming > particularly if there's very visible and useful diagnostic details provided > when they occur. > > Sincerely, > - Ray > > On Sat, Nov 3, 2018, 11:30 Alain Picard via osgi-dev < > osgi-dev@mail.osgi.org wrote: > >> A small note if anyone happens to face the same issue. At the end after >> adding tracing we found out that we had a few resolver chain issues: >> RESOLVER: Candidate permutation failed due to a conflict between imports; >> will try another if possible..... via two dependency chains. >> >> So we had to clear that up and now there is no more startup time issue. >> >> Cheers, >> Alain >> >> On Tue, Oct 23, 2018 at 4:45 AM Alain Picard <pic...@castortech.com> >> wrote: >> >>> Neil, >>> >>> Thanks for the pointers. >>> 2 points...as well >>> >>> 1. This was an RCP application that is still PDE based (can't do >>> everything in this round of refactoring) but now running directly against >>> OSGI (not an Eclipse application. And there are no p2 bundles selected. >>> >>> 2. Well retesting this morning the start time for the console to start >>> outputting content is ~12 seconds. I say outputting since the timestamp of >>> the messages is from about 1 second after start time. Anyway not sure >>> exactly what was done in the last day that would have made such a >>> difference. >>> >>> Cheers, >>> Alain >>> >>> >>> On Tue, Oct 23, 2018 at 4:12 AM Neil Bartlett <njbartl...@gmail.com> >>> wrote: >>> >>>> Two quick points: >>>> >>>> 1. The Felix ResolverImpl is responsible for resolving bundle >>>> constaints (imports and requires). It has absolutely nothing to do with >>>> SCR, so it doesn't matter how many components you have. >>>> >>>> 2. Are you building an Eclipse RCP application? If so, check whether >>>> the org.eclipse.equinox.p2.reconciler.dropins bundle is present. This >>>> bundle is part of Eclipse p2 and it supports the "drop-ins" folder >>>> functionality... it performs a second resolution of the complete set of >>>> installed bundles plus the dropins folder, and it is VERY slow. Most apps >>>> don't need this functionality. By removing it I cut the start time of one >>>> application from nearly 2 minutes (not exaggerating) down to 15 seconds >>>> (still not great, more work to do). >>>> >>>> Regards, >>>> Neil >>>> >>>> On Mon, Oct 22, 2018 at 6:43 PM Alain Picard via osgi-dev < >>>> osgi-dev@mail.osgi.org> wrote: >>>> >>>>> We are experiencing some long startup time in our reafactored >>>>> application that is now heavily using SCR. >>>>> >>>>> We have 125 projects with over 1200 Service Components and it takes >>>>> about 2 minutes to get any output in the console. Some quick analysis >>>>> shows >>>>> that its running the Felix ResolverImpl with something like 5-6 thread >>>>> (that is with Equinox). >>>>> >>>>> I looked in that class but there doesn't seem to be any tracing code, >>>>> only what appears to be some debugging code. >>>>> >>>>> Is this expected? If not what have others used to resolve this issue? >>>>> >>>>> Thanks >>>>> Alain >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
