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
