karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] Predictable Boot Feature Startup Order...
Date Tue, 22 Nov 2016 14:41:36 GMT
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"?

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/
>

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