[
https://issues.apache.org/jira/browse/FELIX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053489#comment-13053489
]
Pierre De Rop commented on FELIX-2994:
--------------------------------------
After more thinking, it is likely that my proposed patch is not well adapted to
the new Filter Index recently introduced in DependencyManager.
Indeed, the proposed patch is activating delayed components when some matching
service listeners are found from the framework.
But this might be problematic because the DM Filter Index is registering a
global/single service listener, which tracks everything.
So, in this case, it would activate every delayed components.
Another problem with my proposed patch is that it does not differentiate a
service lookup, from an actual service usage (like you told me in our gtalk):
and I do agree that looking up a service does not necessarily means that the
service is actually/really used.
Moreover, the patch is doing many loops on all existing service listeners ...
so it is not really optimized when there are many service listeners, and many
delayed components.
So, in the end, I reconsider the problem and maybe another simpler alternative
could just consist in doing the following: When a component is
defined as a delayed component, then, instead of calling the component's start
method,
we could register a ServiceFactory, which would just simply trigger the
invocation of the component's start method ...
So, in this case, the contract would be to put "expensive" code in the
component's start callback (and not in the init callback, which in this case
should only be used to define possible extra/instance bound dependencies ...)
Marcel, what do you think ?
> Delayed Components in Dependency Manager
> ----------------------------------------
>
> Key: FELIX-2994
> URL: https://issues.apache.org/jira/browse/FELIX-2994
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
> Reporter: Pierre De Rop
> Priority: Minor
> Attachments: FELIX-2994.tgz
>
>
> This issue proposes a lightweight implementation for the support of "delayed
> components" in Dependency Manager.
> (see patch attached to this issue).
> It allows components to delay their possibly expensive activation until they
> are really used, and allows
> Dependency Manager to instantiate/initialize components only as needed.
> For system where many services are installed, and where not every services
> are actually used, then this feature
> can significantly speed up startup time, especially when some unused
> components require an expensive
> processing from their "init" / "start" methods.
> A new "setDelayed(boolean)" method has been added in the Component interface,
> and also a new "delayed" state
> has been added in the ComponentDeclaration, allowing to browse delayed
> components from the DM shell.
> Here is a code example which defines a delayed component:
> dm.add(createComponent()
> .setImplementation(DelayedServiceImpl.class)
> .setInterface(DelayedService.class.getName, null)
> .setDelayed(true));
> Implementation notes
> --------------------------
> - By default, components are not delayed (as before).
> - A new DelayedComponentTest has been added in the test sub-project
>
> - This implementation is simple and is not intrusive: DM core classes
> *have not* been modified
> (excepts a micro-modif in ComponentImpl.java, and in
> ComponentDeclaration.java). Basically,
> we track every service listeners, and when a listener is matching a
> delayed component, then
> the component is started. Else, the component is not started, hence
> avoiding the useless component
> instantiation/initialization.
> - A new state has been added in the ComponentDeclaration class
> (STATE_DELAYED), allowing to track
> delayed components from the Dependency Manager shell.
> - The new filter index recently introduced in DM has not yet been used,
> but it might be useful to
> integrate it in the delayed component manager, since the DM indexer
> greatly speeds up service listeners lookup,
> especially when using many (thousands) of services. But this enhancement
> could be done in a next step.
> - The ListenerHook (from ServiceHook specification) is used for the
> implementation: this allows to trigger the
> activation of DM delayed components not only using DependencyManager
> dependencies, but also using other libraries,
> like Declarative Service, iPOJO, blueprint, or even ServiceTracker.
> This is important because
> in our environment, we are using both dependency manager and Declarative
> Service, and we need to be able to
> activate a delayed DM component from a Declarative Service "Reference"
> dependency. ListenerHook
> allows to do this because using ListenerHook, we are able to track every
> service listeners registered in the framework.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
