Hi All,
In the C5 Carbon Kernel, we introduced a new feature call
StartupOrderResolver. The main idea is to overcome some of the limitation
we have in the cardinality of OSGi Service Components and to have implicit
dependencies among the components. You can find more information on the
design/implementation in [1] and [2].
In the recent testing, we came across a very rare race condition in this
implementation which is explained below.
Let's assume there is Component (DeploymentMgtComponent) that is using
StartupOrderResolver, needs to wait until all the Deployment services are
available.
1) The Happy Path
i) A deployment service registers with the OSGi registry (1)
ii) OSGi Registry notifies the ServiceComponent (2a)
iii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver (2b)
iv) StartupOrderResolverUpdates its ServiceMetadata
(v) The timer triggers, if all the required capabilities are ready, notify
the component (3)
2) Problematic Path
i) A deployment service registers with the OSGi registry (1)
ii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver (2b)
iii) StartupOrderResolverUpdates its ServiceMetadata
iv) The timer triggers, if all the required capabilities are ready, notify
the component (3)
v) OSGi Registry notifies the ServiceComponent (2a)
In the problematic path, onAllRequiredCapabilitiesAvailable() method is
called before a reference to the Deployment service is received via the
OSGi registry.
The fix is to delay the method call onAllRequiredCapabilitiesAvailable()
until all the service references are received by the ServiceComponet. But
there is no OOB way of detecting from the outside, whether a particular
component has received a service reference or not.
Hence I came up with the below-mentioned solution, In which I added a new
"StartupServiceCache" and changed the StartupOrder pending capability
detecting logic to use the StartupServiceCache to identify the services
that are already known by the Component.
With this approach, if a ServiceComponent developer wants to rely on
StartupOrderResolver, he will have to follow the same old way and have an
additional entry in the @Reference method in the service component
e.g:
StartupServiceUtils.updateServiceCache("carbon-deployment-mgt",
Deployment.class, deployment);
The proposed solution fixes the issue. With this solution, the developer
will have to add another one entry in the ServiceComponent, which I believe
ok as the developer anyway be putting additional entries in the Components
and Services to make it incorporate with old StartupOrderResolver.
Anyway, I am looking into other possibilities whether we could get rid of
this additional entry.
Any idea/suggestion on this regard is highly appreciated.
[1] https://medium.com/@sameera.jayasoma/startup-order-
resolving-mechanisms-in-osgi-48aecde06389#.vn6p146ts
[2] https://medium.com/@sameera.jayasoma/resolving-startup-
order-of-carbon-components-in-wso2-carbon-5-0-0-497fe3287e67#.drybgj29a
Thanks,
*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [email protected]
mobile: +94772207259 <+94%2077%20220%207259>
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
