[ 
https://issues.apache.org/jira/browse/FELIX-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop closed FELIX-4807.
--------------------------------

> 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)

Reply via email to