[
https://issues.apache.org/jira/browse/FELIX-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4807:
---------------------------------
Description:
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.
was:
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.
> 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)
