Hi David > What is a good way to test for robustness against this phenomenon?
Again, I wish to go on record as saying that bouncing does not mean that anything is wrong, nor is it intrinsically bad. DS Components with a static policy bounce in order to change the references that they use. This in turn will cause other things that depend on them to bounce. The whole point is that the system correctly re-assembles in the end. Declarative works in this way by default because it makes it easy to write very robust components without having to worry about thread safety, and all the complex testing that is needed to verify that thread safety. The only time that you really want to avoid bouncing is if your component’s activation/deactivation is very computationally intensive (e.g. you have to create an in-memory index of a huge database) or if you know that one of your service references will change very regularly. These components are comparatively rare! Best Regards, Tim > On 12 Jul 2018, at 20:41, David Leangen via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > > On the topic of bouncing… > > What is a good way to test for robustness against this phenomenon? Is there > some kind of Monkey Testing [1] framework to help with this? > > > [1] https://en.wikipedia.org/wiki/Monkey_testing > <https://en.wikipedia.org/wiki/Monkey_testing> > > > > >> On Jul 12, 2018, at 23:11, Peter Kriens <peter.kri...@aqute.biz >> <mailto:peter.kri...@aqute.biz>> wrote: >> >> Well, OSGi has a tendency to punish short cuts. In the long run this is very >> valuable, I’ve seen too many software disasters to sleep well at night. >> However, for a developer behind his screen and a looming deadline the long >> term goals are unfortunately not so urgent :-( >> >> Kind regards, >> >> Peter Kriens >> >> >> >>> On 12 Jul 2018, at 13:38, David Leangen via osgi-dev >>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>> >>> >>> As always, thank you VERY much to all of you for your great suggestions. I >>> will look into this from tomorrow. I didn’t know the concept of “bouncing”. >>> That is interesting. Now that I am aware, I will give more thought to it. >>> >>> One thing I have seen stated before on this list is that OSGi is indeed >>> complex, but it is not accidental complexity. It is simply making >>> complexity explicit, and providing the tools to work with complexity. I >>> completely agree with this statement. >>> >>> I am still learning all the time, and am always amazed that there is still >>> so much deeper to go. Thanks for helping me along this journey. >>> >>> >>> Cheers, >>> =David >>> >>> >>> >>>> On Jul 12, 2018, at 17:42, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>>> >>>> If it is a bouncing problem, than you could also try to configure the >>>> behavior using the property >>>> >>>> ds.delayed.keepInstances=true >>>> >>>> From the Apache Felix documentation: >>>> >>>> Whether or not to keep instances of delayed components once they are not >>>> referred to any more. The Declarative Services specifications suggests >>>> that instances of delayed components are disposed off if there is not used >>>> any longer. Setting this flag causes the components to not be disposed off >>>> and thus prevent them from being constantly recreated if often used. >>>> Examples of such components may be EventHandler services. The default is >>>> to dispose off unused components. See FELIX-3039 >>>> <https://issues.apache.org/jira/browse/FELIX-3039> for details. >>>> >>>> http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html >>>> >>>> <http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html> >>>> >>>> Equinox DS had this set by default, while the default in Felix SCR is >>>> false. With the usage of Felix SCR in Eclipse we needed to explicitly set >>>> this parameter to true so the previous behavior persists. >>>> >>>> Mit freundlichen Grüßen / Best regards >>>> >>>> Dirk Fauth >>>> >>>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) >>>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | >>>> www.bosch.com <http://www.bosch.com/> >>>> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com >>>> <mailto:dirk.fa...@de.bosch.com> >>>> >>>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; >>>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar >>>> Denner, >>>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, >>>> Dr. Stefan Hartung, Dr. Markus Heyn, >>>> Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller >>>> >>>> >>>> Von: osgi-dev-boun...@mail.osgi.org >>>> <mailto:osgi-dev-boun...@mail.osgi.org> >>>> [mailto:osgi-dev-boun...@mail.osgi.org >>>> <mailto:osgi-dev-boun...@mail.osgi.org>] Im Auftrag von Tim Ward via >>>> osgi-dev >>>> Gesendet: Donnerstag, 12. Juli 2018 10:22 >>>> An: Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>>; >>>> OSGi Developer Mail List <osgi-dev@mail.osgi.org >>>> <mailto:osgi-dev@mail.osgi.org>> >>>> Betreff: Re: [osgi-dev] Double config >>>> >>>> Hi David, >>>> >>>> >>>> This is a gift! :-) It means your code is not handling the dynamics >>>> correctly and now you know it! >>>> >>>> I’m not sure that there’s quite enough evidence to come to this >>>> conclusion. It could simply be that everything is working fine with a >>>> static policy, and working the way that DS is supposed to. In general a DS >>>> component being bounced like this is nothing to worry about, it’s just a >>>> change rippling through the system, and it’s typically resolved in very >>>> short order. If you do want to reason about why, however, then there are >>>> several places to look. >>>> >>>> For some reason, the Component gets activated, deactivated, then activated >>>> again, which is not desirable. >>>> ... >>>> 1. How can I figure out why this is happening. I have tried many >>>> approaches, but can’t seem to get a clue as to why this is happening. >>>> Since it generally doesn’t seem to happen for other configured components, >>>> I am assuming that it is not a Configurator problem. >>>> >>>> From the rest of your email it is clear that the configured component >>>> provides a service. This will make it lazy by default. You have also >>>> stated that you’re using has a required configuration policy. Therefore it >>>> will only be activated when: >>>> >>>> There is a configuration present >>>> All of the mandatory services are satisfied >>>> Someone is actually using the service >>>> >>>> The component will then be deactivated when any of these things are >>>> no-longer true, and so this means that your component may be being bounced >>>> for several reasons, only one of which is to do with configuration. >>>> >>>> While it seems unlikely to me, you seem to be fairly convinced that the >>>> configuration is at fault so lets start there. >>>> >>>> Does the generated XML file in your bundle actually say that the >>>> configuration is required. This is the configuration used by DS (not the >>>> annotations) at runtime. It’s unlikely that this has gone wrong, but it’s >>>> an easy check >>>> Do you have more than one way of putting configuration into the runtime? >>>> If you are also using File Install, or some other configuration management >>>> agent, then it’s entirely possible that you’re seeing a configuration >>>> update occurring. >>>> Do you have multiple configuration bundles which both contain a >>>> configuration for this component? The configurator will process these one >>>> at a time, and it will result in configuration bouncing >>>> Is it possible that something is forcing a re-resolve of your >>>> configuration bundle or the configurator? This could easily trigger the >>>> configurations to be reprocessed. >>>> >>>> Now in my view the most likely reason for this behaviour is that the >>>> configured component isnot being bounced due to a configuration change. >>>> The most likely suspect is that the component is simply not being used at >>>> that time, and so it is being disposed (DS lazy behaviour). This could >>>> easily happen if one of the dependent services that you mention starts >>>> using your component, and then is bounced (by a configuration update or >>>> whatever) which causes your component to be released. If nobody else is >>>> using your component at the time then it will be deactivated and released. >>>> The easiest way to verify this is to make your component immediate. This >>>> will remove the laziness, and you will get a good idea as to whether the >>>> bounce is caused by things that you depend on, or by things that depend on >>>> you. If making your component immediate removes the “problem” then it >>>> proves that this isn’t a problem at all (and you can then remove the >>>> immediate behaviour again). >>>> >>>> If making your component immediate doesn’t stop the bouncing then the >>>> third set of things to check is the list of services that your component >>>> depends on. Is it possible that one of them is being bounced due to a >>>> configuration update, or perhaps one of their service dependencies being >>>> unregistered/re-registered? As I mentioned before, bouncing of DS >>>> components is simply the way that updates propagate through the system >>>> when services use a static policy. It isn’t inherently a bad thing, but if >>>> you want to avoid it you have to be dynamic all the way down the >>>> dependency graph. Usually this is a lot more effort than it’s worth! >>>> >>>> I hope this helps, >>>> >>>> Tim >>>> >>>> >>>> >>>> On 12 Jul 2018, at 08:39, Peter Kriens via osgi-dev >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>>> >>>> This is a gift! :-) It means your code is not handling the dynamics >>>> correctly and now you know it! >>>> >>>> The cause is that that the DS starts the components before the >>>> Configurator has done its work. The easiest solution seems to be to use >>>> start levels. If your code CAN handle the dynamics, then this is one of >>>> the few legitimate places where startlevels are useful. I usually oppose >>>> it because people do not handle the dynamics correctly and want a short >>>> cut. This is fine until it is not. And the ‘not’ happens guaranteed one >>>> day. So first fix the dynamics, and then think of solutions that improve >>>> the experience. >>>> >>>> For this purpose, enRoute Classic had a >>>> ‘osgi.enroute.configurer.api.ConfigurationDone’ service. If you made an >>>> @Reference to ConfigurationDone then you were guaranteed to not start >>>> before the Configurer had done its magic. Since you did not want to depend >>>> on such a specific service for reasons of cohesion, I developed >>>> AggregateState. One of the aggregated states was then the presence of the >>>> ConfigurationDone service. Although this is also not perfectly cohesive it >>>> at least aggregates all the uncohesive things in one place and it is >>>> configurable. >>>> >>>> Although this works the customer still is not completely happy since also >>>> the Aggregate State feels uncohesive. So we’ve been discussing a new >>>> angle. I want to try to make the Configuration Records _transient_. In >>>> Felix Config Admin you can provide a persistence service (and it was >>>> recently made useful). I was thinking of setting a special property in the >>>> configuration (something like ‘:persistence:transient’). The persistence >>>> layer would then _not_ persist it. I.e. after a restart there would be no >>>> configuration until the Configurer sets it. This will (I expect) seriously >>>> diminish the bouncing caused for these kind of components. >>>> >>>> And if you’re asking why I am still on the enRoute classic Configurer. >>>> Well, it has ‘precious’ fields and they solved a nasty problem. We needed >>>> to use a well defined value but if the user set one of those values, we >>>> wanted to keep the user’s value. Quite a common scenario. With `precious` >>>> fields you rely on default values (so no value for a precious field in the >>>> configurer’s input) but copy the previous value to the newer >>>> configuration, if present. Works quite well. >>>> >>>> I think `transient` and `precious` could be nice extensions to the new >>>> Configurator for R8. >>>> >>>> Hope this helps. Kind regards, >>>> >>>> Peter Kriens >>>> >>>> >>>> On 12 Jul 2018, at 00:48, David Leangen via osgi-dev >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>>> >>>> >>>> Hi! >>>> >>>> A question about component configuration. >>>> >>>> I have a component that has a required configuration policy. Using a (pre >>>> R7) Configurator to configure the component. For some reason, the >>>> Component gets activated, deactivated, then activated again, which is not >>>> desirable. >>>> >>>> Questions: >>>> >>>> 1. How can I figure out why this is happening. I have tried many >>>> approaches, but can’t seem to get a clue as to why this is happening. >>>> Since it generally doesn’t seem to happen for other configured components, >>>> I am assuming that it is not a Configurator problem. >>>> >>>> 2. Is there a way to prohibit this from happening? >>>> >>>> >>>> In the meantime, I will make the dependent services more dynamic so they >>>> are not thrown off by this change, but their behavior is actually correct: >>>> the expectation is that the configured service should only get >>>> instantiated once, so a static @Reference is correct. >>>> >>>> >>>> Thanks! >>>> =David >>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
