Yes that makes sense. After tracing was turned on, the message was pretty clear and we knew where to dig further. Will open an issue.
Alain On Sat, Nov 3, 2018 at 11:49 AM Raymond Auge <raymond.a...@liferay.com> wrote: > 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
