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