Hi All,
I looked further into OSGi related hooks and etc. to check whether there is
any possibility from the OSGi framework to get the notification of a
service registration to the tracker after OSGi has notified all the
components. Unfortunately, It seems OSGi is not providing such mechanism
OOB.
As of now, the only way is to track the services received by the components
separately via the proposed StartupServiceCache.
@Kishanthan: Yes I checked both org.osgi.framework.hooks.service.EventHook
and org.osgi.framework.hooks.service.EventListenerHook, we can use those
hooks to get the even of service registration. But these events are
received before the service is injected to the Service Component. Our
requirement is to get such notification after the Service Component is
notified.
@Dilan: Sorry, I have missed explaining the (A) in the diagram in my
description.
(A) in the diagram, is the following method call. Which basically updated
the StartupServiceCache.
e.g:
StartupServiceUtils.updateServiceCache("carbon-deployment-mgt",
Deployment.class, deployment);
Thanks,
Jayanga.
*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: [email protected]
mobile: +94772207259
<http://wso2.com/signature>
On Thu, Mar 23, 2017 at 11:04 AM, Dilan Udara Ariyaratne <[email protected]>
wrote:
> Hi Jayanga,
>
> Can you describe a little bit on how this StartupServiceCache is working,
> for ex: How it is updated, with what data and so on.
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Wed, Mar 22, 2017 at 7:23 PM, Kishanthan Thangarajah <
> [email protected]> wrote:
>
>> Hi Jayanga,
>>
>> As we spoke offline, did we check on the possibility of using service
>> EvenHook instead of the above "cache" ? Also how the internals work when
>> events are delivered in an order (trackers vs service component
>> references)?
>>
>> Thanks,
>>
>> On Wed, Mar 22, 2017 at 6:37 PM, Jayanga Dissanayake <[email protected]>
>> wrote:
>>
>>> 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-resol
>>> ving-mechanisms-in-osgi-48aecde06389#.vn6p146ts
>>> [2] https://medium.com/@sameera.jayasoma/resolving-startup-o
>>> rder-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>
>>>
>>
>>
>>
>> --
>> *Kishanthan Thangarajah*
>> Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635 <+94%2077%20342%206635>
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
