Re: [osgi-dev] Double config

Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev Thu, 12 Jul 2018 01:43:10 -0700

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

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

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] Im
Auftrag von Tim Ward via osgi-dev
Gesendet: Donnerstag, 12. Juli 2018 10:22
An: Peter Kriens <peter.kri...@aqute.biz>; OSGi Developer Mail List
<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.

1. 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
2. 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.
3. 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
4. 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 is not 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

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Double config

Reply via email to