karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] Predictable Boot Feature Startup Order...
Date Tue, 22 Nov 2016 16:27:37 GMT
Actually, the bundle order has absolutely no effect in Karaf 4.1.
In 4.0.x, when the FeaturesService is called, the wiring is imposed by the
feature service.  The features service uses the OSGi resolver to solve the
features and all the constraints, obtain a wiring, then call the OSGi
framework and forces that already computed wiring to be applied (by using
resolver hooks).
The missing bit which has been added to 4.1 by KARAF-4739 is that the
wiring was not enforced upon reboot. This is fixed by saving the computed
wiring and using it during the reboot.

So while I have no problem changing the ordering of bundles, it's really a
cosmetic change at this point.

2016-11-22 15:41 GMT+01:00 James Carman <james@carmanconsulting.com>:

> Guillaume, I like what you did there, using the wiring to help you decide
> what depends on what to control the order!  This is the type of thing I'm
> looking for.  We should try to put dependencies first, if possible in the
> ordering.  This allows folks to be more wishy-washy when writing features,
> so they don't have to worry about ordering, which I like.  I put a comment
> on the issue.  I'm going to try cloning your repo and using your branch to
> build Karaf, then installing Microbule (if you don't get to it before me)
> to see if it solves my issue I'm seeing.
>
> The only thing I'm wondering is how this plays out in a situation where
> multiple bundles can satisfy the same requirement.  Let's take, for
> example, two bundles:
>
> A imports package com.foo versions [1.0.0,2.0.0)
> B imports package com.foo versions [1.1.0,2.2.0)
>
> Now, A uses B and com.foo is exposed on the public API of B, so they need
> to be on the same page.  Let's assume we have two bundles D1 and D2 which
> export the com.foo package with versions 1.0.0 and 1.1.0 respectively.
> Suppose we have a feature "feature-a" which installs A and D1 (since that's
> the version it needs) and we have "feature-b" which installs "feature-a"
> and D2 (because that's what it needs).  It would be great if both A and B
> are wired to D2, since it's the greater version of com.foo and satisfies
> both needs.  However, when installing "feature-a", you might not even know
> that D2 is going to be available.  Perhaps I'm misunderstanding how all
> this wiring mumbojumbo works, but could this cause issues?  If so, is there
> any way to address it?  Should we even try to address it, or would we just
> say "you're doing it wrong, dummy"?
>

That's the benefit of the Karaf 4 FeaturesService implementation using the
OSGi resolver.
In this case, if both A and B can be wired to D2, D1 won't be installed (if
it's listed with the dependency="true") flag.
In the case it's not flagged as a dependency, D1 will be installed, but not
used.  The same happen if you install A first, then B at a later time,
because all the features are considered globally.
If the constraints conflict somehow, A will be wired to D1 and B to D2.  In
those cases, reboot could cause wiring problems because the felix resolver
is not greedy nor persistent (contrary to the equinox one), so that felix
would resolve the bundles one by one and could lead to unresolvable bundles
because of a wrong ordering (and not resolving them all in one go).
Again, KARAF-4739 should solve the problem.

Guillaume


>
> On Fri, Nov 18, 2016 at 3:33 PM Guillaume Nodet <gnodet@apache.org> wrote:
>
> > I've raised KARAF-4825 with a proposal for a fix, let me know what you
> > think.
> >
> > 2016-11-18 17:41 GMT+01:00 James Carman <james@carmanconsulting.com>:
> >
> > > This was when using the features:install after getting into the
> console.
> > > It really seems funny that it would pick that install order.  Seems
> very
> > > counter-intuitive.  Perhaps there's some room for improvement here.
> > >
> > > On Fri, Nov 18, 2016 at 11:39 AM Guillaume Nodet <gnodet@apache.org>
> > > wrote:
> > >
> > > > The resolver gives a list of bundles without any particular order.
> > Karaf
> > > > just sort them in alphabetic order, so "core" < "spi".
> > > > We could sort them based on the wiring so that importers come after
> > > > exporters (keeping in mind we need to get a list out of a graph).
> > > > Note than this is no effect at all at the time the features are
> > installed
> > > >  because the wiring is imposed to the framework.  If the problem you
> > saw
> > > > was mainly during a subsequent reboot, then that's the one I fixed in
> > > 4.1.
> > > > The bundle used to fix the problem is actually not much tied to karaf
> > and
> > > > could be reused in 3.x I think.
> > > >
> > > > 2016-11-18 17:33 GMT+01:00 James Carman <james@carmanconsulting.com
> >:
> > > >
> > > > > Another issue I'm seeing with 4.0.7 right now is that the install
> > order
> > > > > doesn't really seem to make sense.  For example, I've got a "core"
> > > bundle
> > > > > that requires the "spi" (service provider/plugin interfaces)
> bundle.
> > > My
> > > > > feature lists the "spi" bundle before the "core" bundle, but for
> some
> > > > > reason, Karaf is installing "core" first and then installing "spi"
> > much
> > > > > later.  Is that expected behavior?  It seems strange to me.
> > > > >
> > > > > On Fri, Nov 18, 2016 at 11:30 AM James Carman <
> > > > james@carmanconsulting.com>
> > > > > wrote:
> > > > >
> > > > > > The main issue I faced was when different features install
> > different
> > > > > > versions of the same bundle (my particular problem child was
> GSON I
> > > > > think).
> > > > > >   The main issue that we saw was when the lower version
> > > > installed/started
> > > > > > earlier than the higher version.  So, some bundles would bind
to
> > the
> > > > > lower
> > > > > > version and later bundles which require a higher minor version,
> > would
> > > > > bind
> > > > > > to the higher version.  Hopefully that makes sense :)
> > > > > >
> > > > > >
> > > > > > On Fri, Nov 18, 2016 at 11:23 AM Guillaume Nodet <
> > gnodet@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > Here's the  3.x code
> > > > > >             for (Set<Feature> features : stagedFeatures)
{
> > > > > >                 features.removeAll(installedFeatures);
> > > > > >                 featuresService.installFeatures(features,
> > > > > > EnumSet.of(Option.NoAutoRefreshBundles, Option.NoCleanIfFailure,
> > > > > > Option.ContinueBatchOnFailure));
> > > > > >             }
> > > > > >
> > > > > > The 3.x features service will install the features one by one
in
> a
> > > > given
> > > > > > set however.
> > > > > > The difference may come from the Option.NoAutoRefreshBundles,
but
> > > > that's
> > > > > > the benefit of using the osgi resolver, i.e. the features are
> > > > considered
> > > > > as
> > > > > > a whole ;-)
> > > > > >
> > > > > > Just to refresh my memory, what's the actual use case : is it
a
> > > bundle
> > > > > > startup order or a bundle installation order (which has an impact
> > on
> > > > > > resolution when choosing between the same package exported by
> > > multiple
> > > > > > bundles).
> > > > > > Note that the bundle startup order will be different when
> > rebooting,
> > > > > > whereas when using a single stage, the order should be the same.
> > If
> > > > the
> > > > > > problem is a wiring problem because you have packages exported
by
> > > > > multiple
> > > > > > bundles, I've tried to fix some of this problem in 4.1 by
> ensuring
> > > that
> > > > > the
> > > > > > same wiring is reused after a reboot.
> > > > > >
> > > > > > 2016-11-18 17:13 GMT+01:00 James Carman <
> > james@carmanconsulting.com
> > > >:
> > > > > >
> > > > > > > I know.  I looked at the code.  That's why I was surprised
> when I
> > > had
> > > > > > > issues when trying it that way.  It could be I'm doing
> something
> > > > > strange
> > > > > > > with CXF, but it works in a non-staged setup.  If I get
some
> > > cycles,
> > > > > > > perhaps I can try it again and record the error.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Nov 18, 2016 at 11:11 AM Guillaume Nodet <
> > > gnodet@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Using staged features with one feature per set will
have the
> > > exact
> > > > > same
> > > > > > > > behavior than installing the features one by one.
> > > > > > > >
> > > > > > > > Here's the BootFeaturesInstaller code:
> > > > > > > >
> > > > > > > > List<Set<String>> stagedFeatures =
> parseBootFeatures(features);
> > > > > > > > for (Set<String> features : stagedFeatures)
{
> > > > > > > >     featuresService.installFeatures(features,
> > > > > > > > EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound));
> > > > > > > > }
> > > > > > > > featuresService.bootDone();
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-11-18 17:03 GMT+01:00 James Carman <
> > > > james@carmanconsulting.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Yes, I've tried using staged boot, but in 3.0.x
it caused
> > some
> > > > > > > classpath
> > > > > > > > > issues with CXF.  It would be great if we could
just set up
> > our
> > > > > > > features
> > > > > > > > so
> > > > > > > > > that they're just installed in the order they're
defined.
> > > > > > > > >
> > > > > > > > > On Fri, Nov 18, 2016 at 10:56 AM Guillaume Nodet
<
> > > > > gnodet@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > You mean installing the features one by
one instead of
> all
> > in
> > > > one
> > > > > > go
> > > > > > > ?
> > > > > > > > > > Have you tried using
> > > > > > > > > >   (myfeature1,myfeature2),(myfeature3,myfeature4)
> > > > > > > > > > so that you end up with 2 stages ?
> > > > > > > > > > Ultimately, you can use
> > > > > > > > > >   (myfeature1),(myfeature2),(myfeature3),(myfeature4)
> > > > > > > > > >
> > > > > > > > > > 2016-11-18 16:44 GMT+01:00 James Carman
<
> > > > > > james@carmanconsulting.com
> > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Karaf 3.0.8+ now provides predictable
boot feature
> > startup
> > > > > order,
> > > > > > > but
> > > > > > > > > the
> > > > > > > > > > > 4.0.x line does not provide that guarantee.
 It
> > apparently
> > > > > tries
> > > > > > to
> > > > > > > > be
> > > > > > > > > > > smart and figure out what you need,
but sometimes it
> just
> > > > works
> > > > > > > > better
> > > > > > > > > if
> > > > > > > > > > > we can let the user control things
explicitly.  Is
> there,
> > > > > > perhaps,
> > > > > > > a
> > > > > > > > > > > compromise here?  Could we perhaps
have a switch in the
> > > > > > > > > > > org.apache.karaf.features.cfg file
that allows you to
> > turn
> > > on
> > > > > > > manual
> > > > > > > > > > > control of the startup order?  I'm
not the only one who
> > has
> > > > > > > > encountered
> > > > > > > > > > > this issue.  There have been emails
recently where
> other
> > > > folks
> > > > > > have
> > > > > > > > > > > observed it.  Thoughts?
> > > > > > > > > > >
> > > > > > > > > > > James
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ------------------------
> > > > > > > > > > Guillaume Nodet
> > > > > > > > > > ------------------------
> > > > > > > > > > Red Hat, Open Source Integration
> > > > > > > > > >
> > > > > > > > > > Email: gnodet@redhat.com
> > > > > > > > > > Web: http://fusesource.com
> > > > > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > > > > > ------------------------
> > > > > > > > Red Hat, Open Source Integration
> > > > > > > >
> > > > > > > > Email: gnodet@redhat.com
> > > > > > > > Web: http://fusesource.com
> > > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Red Hat, Open Source Integration
> > > > > >
> > > > > > Email: gnodet@redhat.com
> > > > > > Web: http://fusesource.com
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Red Hat, Open Source Integration
> > > >
> > > > Email: gnodet@redhat.com
> > > > Web: http://fusesource.com
> > > > Blog: http://gnodet.blogspot.com/
> > > >
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message