Hi, +1 to introduce the autorefresh property.
About the default on/off, it's pretty easy to make a custom distribution with Karaf so users can choose depending on his usage of Karaf. We just have to add documentation about this if we change the default value from 4.2.x to 4.3.x. regards, François [email protected] Le 08/01/2021 à 09:07, Grzegorz Grzybek a écrit : > Hello > > Thanks JBO for the proposal, which concerns very important "feature, > not a problem" of OSGi... > > To be honest I don't have clear statement about when to disable > autorefresh (4.3 or 5.x), but let me share my view on it. > > We (Red Hat Fuse team) have been struggling with "unnecessary > refreshes" for long time in Fuse 6, which is based on Karaf 2.4, but > with Karaf 4.x resolver and In Fuse 7 (based on Karaf 4). Fuse 6 in > fabric mode is something more complex than pure Karaf, as it has the > concept of "profiles" which allow to collect features + bundles (+ > bunch of other stuff) in single entity to be assigned to a container. > And a container may have many profiles (thus many sets of features + > bundles) assigned. > What (from user point of view) was a simple operation like: > `container-add-profile <container> <profile>`, may end up with few > minutes of Maven downloading and a cycle of bundle refreshes. > > Putting Fuse 6/Fabric8 aside, Karaf feature was indeed (as JBO > explained) a way to install many bundles in "a transaction" without a > need to go through all existing bundles and refreshing them as needed. > So my first hesitation is - how many `feature:install` commands (with > autoRefresh = false) will have to be followed by explicit `osgi:refresh`? > > On the other hand, when we stop treating Karaf as very-long running > application server, how many times will we even perform > `feature:install`? We'll rather have a custom distro, where all > necessary bundles are installed/available from start. Here, > autoRefresh=false is indeed more natural. > > Another thing to remember is that Karaf resolver may "reach out" to > bundles that have to be refreshed upon feature installation, if there > are relevant "wires" between the bundles. We've seen many times that > refreshing a bundle (we had this with ActiveMQ + Camel) doesn't > necessary lead to refresh of all the bundles, because there was no > wire between the bundles - because maven-bundle-plugin didn't generate > one, because the ONLY link between a blueprint bundle with Camel > context and ActiveMQ bundle was «from="failover:xxx"» Camel > declaration, which wasn't recognized by maven-bundle-plugin plugins. > > Over the time, I've been personally involved in "fixing unnecessary > refreshes" bugs many times - like splitting pax-logging into > pax-logging-api + pax-logging-service (done by +Guillaume Nodet > <mailto:[email protected]> ) or splitting pax-logging-log4j2 into a > bundle + fragment (done by JBO). In Fuse we were carefully influencing > etc/startup.properties and rewriting many features to be more > consistent and less vulnerable to unnecessary refreshes. > > But summarizing, I'd keep autoRefresh=true in all the scenarios, where > Karaf is used as "application server" and switch it to > autoRefresh=false in µservices / custom distro / single start mode. > And looking forward Karaf 5 and new feature mechanism, I'd rather turn > autoRefresh off in Karaf 5... > > regards > Grzegorz Grzybek > > pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <[email protected] > <mailto:[email protected]>> napisał(a): > > Hi everyone, > > We got several user feedback, complaining about unexpected and > cascaded (unrelated) refresh while installing features. > > As reminder, a refresh can happen when: > - bundle A imports package foo:1 and a bundle provides newer foo > package version. In that case, the features service will refresh A > to use the newest package version. > - bundle A has an optional import to package foo and a bundle > provides this package. In that case, the features service will > refresh A to actually use the import as it’s a "resolved" optional. > - bundle A is wired to bundle B (from a package perspective or > requirement) and B is refreshed. In that case, the features > service will refresh A as B is itself refreshed (for the previous > reasons for instance). This can cause "cascading" refresh. > > A refresh means that a bundle can be restarted (if the bundle > contains an activator or similar (DS component, blueprint bundle)). > > In this PR https://github.com/apache/karaf/pull/1287 > <https://github.com/apache/karaf/pull/1287> > <https://github.com/apache/karaf/pull/1287 > <https://github.com/apache/karaf/pull/1287>>, I propose to > introduce a new property autoRefresh in > etc/org.apache.karaf.features.cfg to disable the auto refresh by > the features service (and let the user decides when he wants to > trigger refresh with bundle:refresh command for instance). > I propose to keep autoRefresh=true on 4.2.x and turn > autoRefresh=false on 4.3.x. > > Thoughts ? > > On the other hand (and to prepare the "path" to Karaf5), I have > created a new "simple features service" (PR will be open soon) that: > > - just take the features definition in order (ignoring start level) > - ignore requirement/capability (no resolver) > - no auto refresh > > Basically, if you have the following feature definition: > > <feature name="foo" version="1.0"> > <feature>bar</feature> > <bundle>A</bundle> > <bundle>B</bundle> > </feature> > > The features service will fully install/start bar feature first, > then bundle A, then bundle B. > To use this "simple features services, you just have to replace > org.apache.karaf.features.core by org.apache.karaf.features.simple > bundle in etc/startup.properties (or custom distribution). > > It’s similar to the Karaf 5 extension behavior (I will share > complete details about Karaf 5 and its concepts (module, > extension, …) very soon, but that’s another thread ;)). > > The big advantages of this approach is: > - predictable/deterministic provisioning (if it works fine, it > works again) > - faster deployment (I estimated the gain to about 70%) > > Thoughts ? > > If you agree, I will move forward on both tasks. > > Thanks, > Regards > JB >
