On Sun, Aug 26, 2018 at 1:35 AM 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???
>
I can't explain this either. The only suggestions I can make are:
1) Write a deactivate method, stick a breakpoint on it and look at the
stack. That might give you a clue as to why and how you got there.
2) Create a demonstrator project and raise a bug against the SCR
implementation.
>
> —> 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).
>
This is indeed my suspicion based on what you have described. Have you
tried using a later SCR implementation, just in case it's a bug that's
already been fixed?
Neil
>
>
> 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
