David,
In my own journey I have had (and still does have) my share of moments
where I'm not sure what's happening. We are still on Equinox/PDE (can't
wait to switch to BND but that will have to wait a bit), and there I have
used the tracing to get insight into the service registry events. With
Equinox you can turn tracing under o.e.osgi. The keys are debug and
debug/services. This activates the tracing from Felix SCR, so that is not
limited to Equinox, but I'm not sure how you would activate it if not using
Equinox.
HTH,
Alain
On Sat, Aug 25, 2018 at 8:35 PM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> Thank you again for all the great tips in this thread. I have taken the
> time to review concurrency, reread all the blogs, articles, and email
> messages in detail, and I have done a fairly thorough review of all my
> code. I have identified a lot of places where there was potential for
> concurrency errors, and I made a lot of simplifications (mostly by
> eliminating any clever use of concurrency or synchronization when it wasn’t
> really providing any tangible benefit, and only introducing risk). I also
> reviewed again the DS lifecycle, as well as Trackers. I am pretty confident
> that my understanding of the concurrent issues, and consequently my system,
> are now in good shape. I think I can handle the dynamics now in a robust
> way (though I still don’t know how to test for it to confirm).
>
> However, I am experiencing one problem on startup still that baffles me.
>
> Take this component:
>
>
> @Component(
> factory = ...,
> configurationPid = ...,
> configurationPolicy = ConfigurationPolicy.REQUIRE)
> public class D
> implements Descriptor
> {
> @Reference( scope = ReferenceScope.PROTOTYPE_REQUIRED )
> private WriterFactory.JsonWriterFactory factory;
>
> @Activate
> void activate( Configuration.Config config )
> {
> ...
> }
>
> ...
> }
>
>
> There is really nothing more to the component that this. One static
> reference (which is satisfied), and a required config (which is available).
>
> The factory basically looks like this (called from a different component
> that instantiates this tracker):
>
>
> public class ComponentFactoryTracker
> extends ServiceTracker<ComponentFactory, ComponentInstance>
> {
> public ConfinementAwareComponentFactoryTracker( BundleContext context,
> Filter filter )
> {
> super( context, filter, null );
> }
>
> @Override
> public ComponentInstance addingService(
> ServiceReference<ComponentFactory> reference )
> {
> final ComponentFactory cf = context.getService( reference );
> final Dictionary<String, Object> properties = new Hashtable<>();
> properties.put( ... );
> final ComponentInstance instance = cf.newInstance( properties );
> return instance;
> }
>
> @Override
> public void removedService( ServiceReference<ComponentFactory>
> reference, ComponentInstance instance )
> {
> context.ungetService( reference );
> instance.dispose();
> }
> }
>
> Fairly simple.
>
> The system starts up, and the D component (and others like it) also
> starts. Then bouncing happens. When things finally settle down after one
> bounce, D (and others like it) gets deactivated. This is where I start
> pulling my hair out. **Why** does it get deactivated???
>
> —> The one and only static reference is available. Check.
>
> —> The configuration is available. Check.
>
> —> The ComponentFactory services are enabled. Check.
>
> However, despite all the prerequisites being available, D (and others) are
> getting deactivated. I even created an immediate service that references D
> (and others) to ensure that somebody was calling it. Nothing. Nada. All
> that I can validate is that as D (and others) get deactivated, they are
> unbound from this test service.
>
> If I restart any bundle that causes D to refresh, then the state of the
> system comes up correctly. It is only upon initial startup that this
> problem occurs.
>
> If I try injecting some service that potentially changes startup order,
> sometimes it works, but I have not yet figured out the pattern. In any
> case, since the prerequisites for the service are available, I don’t see
> why on Earth that should matter, anyway. Unless maybe there is a bug in SCR
> for some edge case (felix version 2.0.2).
>
>
> I am at a loss...
>
>
> Cheers,
> =David
>
>
>
> On Jul 14, 2018, at 4:05, David Leangen via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>
> Hi Tim,
>
> 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.
>
>
> Thanks. Understood. I did not mean to imply anything about “goodness” or
> “badness”, but it is good to have that on record.
>
> So, my question was: knowing that this happens, is there a good way to
> test against it? My understanding is that currently there is not.
>
>
> Cheers,
> =David
>
> _______________________________________________
> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
