Pierre De Rop created FELIX-4807:
------------------------------------
Summary: 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: dependencymanager-4.0.0
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)
