[
https://issues.apache.org/jira/browse/FELIX-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4807:
---------------------------------
Fix Version/s: (was: dependencymanager-4.0.0)
org.apache.felix.dependencymanager-r1
> New thread model for Dependency Manager
> ---------------------------------------
>
> Key: FELIX-4807
> URL: https://issues.apache.org/jira/browse/FELIX-4807
> Project: Felix
> Issue Type: New Feature
> Components: Dependency Manager
> Reporter: Pierre De Rop
> Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r1
>
>
> This issue describes the new concurrency principles that form the basis for
> the new upcoming Dependency Manager 4.0 version:
> \\
> * In order to support highly concurrent systems, the Dependency Manager has
> been totally reworked using a kind of actor thread model, where all external
> events that influence the state of a component are handled serially (in FIFO
> order), but not using synchronizations, blocking locks, or any read/write
> locks.
> Instead of that, a lock-free serial queue is internally maintained for each
> component, and all events (component dependency events, bundle events) are
> then scheduled in the component queue, which is executed by the first thread
> that triggers an event for a given component.
> * The new thread model may sometimes make it easier to develop components,
> because dependency injection callbacks are now serially invoked, and there is
> no need to synchronize callbacks anymore. However if a dependency is injected
> while another thread may use the component, then it is still necessary to
> store injected service dependencies in thread safe datastructure or volatiles
> variable.
> * Optionally, a shared threadpool can be registered in the registry by any
> management agent bundle, in order to allow the parallel execution of
> component queues. However, all events scheduled in a given component queue
> are still executed in FIFO order, but independent components may each be
> managed and activated concurrently with respect to each other (in other
> worlds, the components remains "single threaded", but multiple components can
> be started concurrently).
> * In order to enable parallel activation of components, you first have to
> register an instance of the org.apache.felix.dm.ComponentExecutorFactory
> service. That factory will then be used by DependencyManager to create an
> Executor of your choice for each Component, typically a shared threadpool
> configured by yourself.
> * If you want to ensure that all Components are initialized after the
> ComponentExecutorFactory is registered in the OSGI registry, you can use the
> {{org.apache.felix.dependencymanager.parallel}} OSGi system property which
> specifies the list of components which must wait for the
> ComponentExecutorFactory service. This property value can be set to a
> wildcard {{*}}, or a list of components implementation class prefixes (comma
> separated). So, all components whose class name starts with the specified
> prefixes will be cached until the ComponentExecutorFactory service is
> registered (In this way, it is not necessary to use the StartLevel service if
> you want to ensure that all components are started concurrently).
> Notice that if the ComponentExecutorFactory implementation and all its
> dependent services are defined using the Dependency Manager API, then you
> have to list the package of such components with a "!" prefix, in order to
> indicate that those components must not wait for a ComponentExecutorFactory
> service (since they are part of the ComponentExecutorFactory implementation
> !).
> See
> dependencymanager-samples/org.apache.felix.dependencymanager.samples/bnd.bnd
> and
> org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/tpool/
> for a concrete example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
