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> 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 >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
