You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@apache.org> on 2016/10/03 16:02:16 UTC
[DISCUSS] Persistent wiring framework
I have a use case where the wiring is a bit complicated.
Karaf uses the felix resolver to compute the full wiring and then applies
it.
At this point, all the bundles are resolved and started correctly.
If Karaf is restarted, the framework restarts and resolves the bundles on
its own, using a bad solution (because the resolver is not greedy) which
leaves some bundles in a non resolvable state (i.e. without refreshing some
bundles).
At this point, I've tried to have Karaf stores the computed wiring so that
it can be re-applied when restarting. Unfortunately, in my very case, the
wiring is done in such a way that nearly all bundles needs to be refreshed,
even the one containing the bundle hook, so that's bound to deadlocks and
various problems.
I'm left with two solutions :
* implement a framework extension to minimize the chances to have to
refresh the bundle containing the resolver hook
* implement a persistent resolution in felix
I don't mind either way, but I wonder if instead of implementing it in
Karaf, it could be done in the framework in a slightly more robust way
(i.e. not contained in a bundle which itself is bound to refreshes, etc...)
and may be reused by others.
Thoughts ?
Guillaume
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Persistent wiring framework
Posted by Guillaume Nodet <gn...@apache.org>.
I came up with the following extension:
https://github.com/apache/karaf/blob/master/features/extension/src/main/java/org/apache/karaf/features/extension/Activator.java
It seems to work correctly so far. I suppose it would be even faster to
have it in the framework to avoid going through the resolver at all, but it
seems to fulfill my needs.
2016-10-03 18:02 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> I have a use case where the wiring is a bit complicated.
> Karaf uses the felix resolver to compute the full wiring and then applies
> it.
> At this point, all the bundles are resolved and started correctly.
> If Karaf is restarted, the framework restarts and resolves the bundles on
> its own, using a bad solution (because the resolver is not greedy) which
> leaves some bundles in a non resolvable state (i.e. without refreshing some
> bundles).
> At this point, I've tried to have Karaf stores the computed wiring so that
> it can be re-applied when restarting. Unfortunately, in my very case, the
> wiring is done in such a way that nearly all bundles needs to be refreshed,
> even the one containing the bundle hook, so that's bound to deadlocks and
> various problems.
>
> I'm left with two solutions :
> * implement a framework extension to minimize the chances to have to
> refresh the bundle containing the resolver hook
> * implement a persistent resolution in felix
>
> I don't mind either way, but I wonder if instead of implementing it in
> Karaf, it could be done in the framework in a slightly more robust way
> (i.e. not contained in a bundle which itself is bound to refreshes, etc...)
> and may be reused by others.
>
> Thoughts ?
>
> Guillaume
>
> --
> ------------------------
> 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/
Re: [DISCUSS] Persistent wiring framework
Posted by Guillaume Nodet <gn...@apache.org>.
2016-10-03 22:12 GMT+02:00 Karl Pauls <ka...@gmail.com>:
> On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
> > An extension sounds doable.
> > However, I found something weird:
> >
> > https://github.com/apache/felix/blob/trunk/framework/
> > src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
> >
> > Is that expected that the framework is using the classloader loading the
> > framework instead of the classloader from the extension bundle ?
>
>
> Yeah, that is a little confusing but the point is that the extension bundle
> will have the same class loader. It's content has been added to the class
> loader of felix at this point (hopefully) and the wiring we use for the
> extension bundle will just return the class loader of felix (or at least
> the ExtensionManager).
>
> Granted, it looks a little confusing so you could argue it should still get
> the class loader via the normal api (never mind it being the same result).
> I don't think that should cause any issues.
>
Ok, thx.
Actually, I had a typo in my activator name, so I blamed the somewhat
crypted code for the ClassNotFoundException ;-)
>
> regards,
>
> Karl
>
>
> >
> > 2016-10-03 18:14 GMT+02:00 Richard S. Hall <he...@ungoverned.org>:
> >
> > > On 10/3/16 12:02 , Guillaume Nodet wrote:
> > >
> > >> I have a use case where the wiring is a bit complicated.
> > >> Karaf uses the felix resolver to compute the full wiring and then
> > applies
> > >> it.
> > >> At this point, all the bundles are resolved and started correctly.
> > >> If Karaf is restarted, the framework restarts and resolves the bundles
> > on
> > >> its own, using a bad solution (because the resolver is not greedy)
> which
> > >> leaves some bundles in a non resolvable state (i.e. without refreshing
> > >> some
> > >> bundles).
> > >> At this point, I've tried to have Karaf stores the computed wiring so
> > that
> > >> it can be re-applied when restarting. Unfortunately, in my very case,
> > the
> > >> wiring is done in such a way that nearly all bundles needs to be
> > >> refreshed,
> > >> even the one containing the bundle hook, so that's bound to deadlocks
> > and
> > >> various problems.
> > >>
> > >> I'm left with two solutions :
> > >> * implement a framework extension to minimize the chances to have
> to
> > >> refresh the bundle containing the resolver hook
> > >> * implement a persistent resolution in felix
> > >>
> > >> I don't mind either way, but I wonder if instead of implementing it in
> > >> Karaf, it could be done in the framework in a slightly more robust way
> > >> (i.e. not contained in a bundle which itself is bound to refreshes,
> > >> etc...)
> > >> and may be reused by others.
> > >>
> > >> Thoughts ?
> > >>
> > >
> > > I don't have a strong opinion, but we had always tried to avoid caching
> > > too much run-time state in the framework cache because this increases
> the
> > > opportunity for the framework cache to become corrupt and then
> > subsequently
> > > fail to restart. In a perfect world, it seems like it would be nice if
> > this
> > > could be a resolver hook implemented externally (and generically) to
> > > provide a management agent service where an agent could attempt to save
> > > resolution state and the resolver hook would be responsible for trying
> to
> > > recreate the saved state upon subsequent startups. Then the framework's
> > > cache stays out of the whole scenario. Perhaps that is wishful
> thinking.
> > >
> > > I believe Equinox' resolves are persisted across executions, so it is
> not
> > > unheard of and does have benefits if implemented well of reducing
> startup
> > > time on subsequent executions by avoid re-resolving complex systems.
> > >
> > > -> richard
> > >
> > >
> > >> Guillaume
> > >>
> > >>
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Persistent wiring framework
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet <gn...@apache.org> wrote:
> An extension sounds doable.
> However, I found something weird:
>
> https://github.com/apache/felix/blob/trunk/framework/
> src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
>
> Is that expected that the framework is using the classloader loading the
> framework instead of the classloader from the extension bundle ?
Yeah, that is a little confusing but the point is that the extension bundle
will have the same class loader. It's content has been added to the class
loader of felix at this point (hopefully) and the wiring we use for the
extension bundle will just return the class loader of felix (or at least
the ExtensionManager).
Granted, it looks a little confusing so you could argue it should still get
the class loader via the normal api (never mind it being the same result).
I don't think that should cause any issues.
regards,
Karl
>
> 2016-10-03 18:14 GMT+02:00 Richard S. Hall <he...@ungoverned.org>:
>
> > On 10/3/16 12:02 , Guillaume Nodet wrote:
> >
> >> I have a use case where the wiring is a bit complicated.
> >> Karaf uses the felix resolver to compute the full wiring and then
> applies
> >> it.
> >> At this point, all the bundles are resolved and started correctly.
> >> If Karaf is restarted, the framework restarts and resolves the bundles
> on
> >> its own, using a bad solution (because the resolver is not greedy) which
> >> leaves some bundles in a non resolvable state (i.e. without refreshing
> >> some
> >> bundles).
> >> At this point, I've tried to have Karaf stores the computed wiring so
> that
> >> it can be re-applied when restarting. Unfortunately, in my very case,
> the
> >> wiring is done in such a way that nearly all bundles needs to be
> >> refreshed,
> >> even the one containing the bundle hook, so that's bound to deadlocks
> and
> >> various problems.
> >>
> >> I'm left with two solutions :
> >> * implement a framework extension to minimize the chances to have to
> >> refresh the bundle containing the resolver hook
> >> * implement a persistent resolution in felix
> >>
> >> I don't mind either way, but I wonder if instead of implementing it in
> >> Karaf, it could be done in the framework in a slightly more robust way
> >> (i.e. not contained in a bundle which itself is bound to refreshes,
> >> etc...)
> >> and may be reused by others.
> >>
> >> Thoughts ?
> >>
> >
> > I don't have a strong opinion, but we had always tried to avoid caching
> > too much run-time state in the framework cache because this increases the
> > opportunity for the framework cache to become corrupt and then
> subsequently
> > fail to restart. In a perfect world, it seems like it would be nice if
> this
> > could be a resolver hook implemented externally (and generically) to
> > provide a management agent service where an agent could attempt to save
> > resolution state and the resolver hook would be responsible for trying to
> > recreate the saved state upon subsequent startups. Then the framework's
> > cache stays out of the whole scenario. Perhaps that is wishful thinking.
> >
> > I believe Equinox' resolves are persisted across executions, so it is not
> > unheard of and does have benefits if implemented well of reducing startup
> > time on subsequent executions by avoid re-resolving complex systems.
> >
> > -> richard
> >
> >
> >> Guillaume
> >>
> >>
> >
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
--
Karl Pauls
karlpauls@gmail.com
Re: [DISCUSS] Persistent wiring framework
Posted by Guillaume Nodet <gn...@apache.org>.
An extension sounds doable.
However, I found something weird:
https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
Is that expected that the framework is using the classloader loading the
framework instead of the classloader from the extension bundle ?
2016-10-03 18:14 GMT+02:00 Richard S. Hall <he...@ungoverned.org>:
> On 10/3/16 12:02 , Guillaume Nodet wrote:
>
>> I have a use case where the wiring is a bit complicated.
>> Karaf uses the felix resolver to compute the full wiring and then applies
>> it.
>> At this point, all the bundles are resolved and started correctly.
>> If Karaf is restarted, the framework restarts and resolves the bundles on
>> its own, using a bad solution (because the resolver is not greedy) which
>> leaves some bundles in a non resolvable state (i.e. without refreshing
>> some
>> bundles).
>> At this point, I've tried to have Karaf stores the computed wiring so that
>> it can be re-applied when restarting. Unfortunately, in my very case, the
>> wiring is done in such a way that nearly all bundles needs to be
>> refreshed,
>> even the one containing the bundle hook, so that's bound to deadlocks and
>> various problems.
>>
>> I'm left with two solutions :
>> * implement a framework extension to minimize the chances to have to
>> refresh the bundle containing the resolver hook
>> * implement a persistent resolution in felix
>>
>> I don't mind either way, but I wonder if instead of implementing it in
>> Karaf, it could be done in the framework in a slightly more robust way
>> (i.e. not contained in a bundle which itself is bound to refreshes,
>> etc...)
>> and may be reused by others.
>>
>> Thoughts ?
>>
>
> I don't have a strong opinion, but we had always tried to avoid caching
> too much run-time state in the framework cache because this increases the
> opportunity for the framework cache to become corrupt and then subsequently
> fail to restart. In a perfect world, it seems like it would be nice if this
> could be a resolver hook implemented externally (and generically) to
> provide a management agent service where an agent could attempt to save
> resolution state and the resolver hook would be responsible for trying to
> recreate the saved state upon subsequent startups. Then the framework's
> cache stays out of the whole scenario. Perhaps that is wishful thinking.
>
> I believe Equinox' resolves are persisted across executions, so it is not
> unheard of and does have benefits if implemented well of reducing startup
> time on subsequent executions by avoid re-resolving complex systems.
>
> -> richard
>
>
>> Guillaume
>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Persistent wiring framework
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/3/16 12:02 , Guillaume Nodet wrote:
> I have a use case where the wiring is a bit complicated.
> Karaf uses the felix resolver to compute the full wiring and then applies
> it.
> At this point, all the bundles are resolved and started correctly.
> If Karaf is restarted, the framework restarts and resolves the bundles on
> its own, using a bad solution (because the resolver is not greedy) which
> leaves some bundles in a non resolvable state (i.e. without refreshing some
> bundles).
> At this point, I've tried to have Karaf stores the computed wiring so that
> it can be re-applied when restarting. Unfortunately, in my very case, the
> wiring is done in such a way that nearly all bundles needs to be refreshed,
> even the one containing the bundle hook, so that's bound to deadlocks and
> various problems.
>
> I'm left with two solutions :
> * implement a framework extension to minimize the chances to have to
> refresh the bundle containing the resolver hook
> * implement a persistent resolution in felix
>
> I don't mind either way, but I wonder if instead of implementing it in
> Karaf, it could be done in the framework in a slightly more robust way
> (i.e. not contained in a bundle which itself is bound to refreshes, etc...)
> and may be reused by others.
>
> Thoughts ?
I don't have a strong opinion, but we had always tried to avoid caching
too much run-time state in the framework cache because this increases
the opportunity for the framework cache to become corrupt and then
subsequently fail to restart. In a perfect world, it seems like it would
be nice if this could be a resolver hook implemented externally (and
generically) to provide a management agent service where an agent could
attempt to save resolution state and the resolver hook would be
responsible for trying to recreate the saved state upon subsequent
startups. Then the framework's cache stays out of the whole scenario.
Perhaps that is wishful thinking.
I believe Equinox' resolves are persisted across executions, so it is
not unheard of and does have benefits if implemented well of reducing
startup time on subsequent executions by avoid re-resolving complex systems.
-> richard
>
> Guillaume
>