[
https://issues.apache.org/jira/browse/BROOKLYN-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752261#comment-16752261
]
Aled Sage commented on BROOKLYN-608:
------------------------------------
+*Spotting Problems*+
To avoid this kind of problem in the future, we want to ensure that bundles are
not being stopped and restarted as part of a normal startup. A good thing to
search for (and fix) is:
{noformat}
grep -E -i "refresh|rewire|stopping bundle" data/log/brooklyn.info.log{noformat}
+*Faster startup*+
To avoid the problem, and to allow Karaf to startup quickly, I believe that
best practice is to simplify Karaf's dependency resolution job. We don't want
to ask it to start lots of bundles at the same time, because the constraint
satisfaction problem is NP-Complete:
[https://stackoverflow.com/questions/2085106/is-the-resolution-problem-in-osgi-np-complete]
We can simplify Karaf's job considerably by splitting it into groups of
features/bundles. We start with the core karaf stuff we want, then the next
level of low-level libraries/dependencies, etc. We ensure that early in this
phased approach we have installed the correct bundle version (i.e. highest
version that is required), so that wiring will not be subsequently redone
(causing bundles to stop/start).
This is tricky for Brooklyn because we have quite a few external
dependencies/features - if a dependency of one of those features changes, it
could be newer than the one we install earlier (thus causing rewiring).
Therefore it is a regular chore to check this, and to fix rewiring problems.
We should look at how to break down the dependencies into distinct logical
groups that we can more easily reason about.
> karaf startup: javax.annotation-api stopped + restarted (can cause startup to
> fail)
> -----------------------------------------------------------------------------------
>
> Key: BROOKLYN-608
> URL: https://issues.apache.org/jira/browse/BROOKLYN-608
> Project: Brooklyn
> Issue Type: Bug
> Reporter: Aled Sage
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When starting Brooklyn karaf 1.0.0-SNAPSHOT, we see in the log that
> \{{javax.annotation-api/1.2.0}} is started and then stopped again (to be
> replaced with v1.3)
> {noformat}
> 2019-01-25T10:10:40,561 - INFO 11 o.a.k.f.i.s.FeaturesServiceImpl
> [tures-3-thread-1] Stopping bundles:
> 2019-01-25T10:10:40,562 - INFO 11 o.a.k.f.i.s.FeaturesServiceImpl
> [tures-3-thread-1] javax.annotation-api/1.2.0
> 2019-01-25T10:10:40,563 - INFO 11 o.a.k.f.i.s.FeaturesServiceImpl
> [tures-3-thread-1] org.ops4j.pax.logging.pax-logging-log4j2/1.10.1{noformat}
> This causes many other bundles to be reloaded. In Brooklyn, this takes a few
> seconds. But in downstream projects that embed or build on Brooklyn, the
> consequence can be much worse - unloading javax.annotation-api causes so many
> bundles to be stopped that Karaf really struggles to figure out the
> dependencies - CPU usage maxes out for several minutes, and then it seemingly
> hangs (cpu goes to zero, and nothing else appears in the logs).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
