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