svn commit: r1626394 - in /felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager: design.txt src/org/apache/felix/dm/DependencyManager.java

[pd...@apache.org]

Author: pderop
Date: Sat Sep 20 07:48:00 2014
New Revision: 1626394

URL: http://svn.apache.org/r1626394
Log:
Added comments in the core design.txt document.
Added in the DependencyManager class. 
Allow to disable parallelism (the DependencyManager.setThreadPool(null)) method can now be invoked, and in this case,
the component won't be activated using a threadpool registered in the OSGi service registry.

Modified:
    felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt
    felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/src/org/apache/felix/dm/DependencyManager.java

Modified: felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt
URL: http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt?rev=1626394&r1=1626393&r2=1626394&view=diff
==============================================================================
--- felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt (original)
+++ felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt Sat Sep 20 07:48:00 2014
@@ -17,6 +17,16 @@ This prototype demonstrates the new conc
  * State in the component and dependency can only be modified via the serial executor
    thread. This means we don't need explicit synchronization anywhere.
 
+20 sept 2014 (pderop):
 
+ * Added support for concurrent mode: you can now register in the OSGi service registry a
+   threadpool (java.util.concurrent.Executor) service using the
+   "target=org.apache.felix.dependencymanager" service property, and using the
+   "org.apache.felix.dependencymanager.parallel=true system property". This will allow to handle all
+   component dependencies and all component lifecycle callbacks concurrently. Notice that component
+   events are still handled serially. The only difference is that multiple components can be handled
+   in parallel. See the
+   org.apache.felix.dependencymanager/src/org/apache/felix/dm/impl/DispatchExecutor.java for for
+   informations.
 
 

Modified: felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/src/org/apache/felix/dm/DependencyManager.java
URL: http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/src/org/apache/felix/dm/DependencyManager.java?rev=1626394&r1=1626393&r2=1626394&view=diff
==============================================================================
--- felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/src/org/apache/felix/dm/DependencyManager.java (original)
+++ felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/src/org/apache/felix/dm/DependencyManager.java Sat Sep 20 07:48:00 2014
@@ -81,6 +81,7 @@ public class DependencyManager {
     private final Logger m_logger;
     private final List<Component> m_components = new CopyOnWriteArrayList<>();
     private volatile Executor m_threadPool;
+    private volatile boolean m_setThreadPoolMethodCalled = false;
 
     // service registry cache
     private static ServiceRegistryCache m_serviceRegistryCache;
@@ -140,9 +141,18 @@ public class DependencyManager {
     /**
      * Sets a threadpool to this dependency manager. All added/removed components will then be handled
      * in parallel, using the provided threadpool.
+     * 
+     * Notice that you can also enable parallelism by registering an Executor in the OSGi service registry with
+     * a "target=org.apache.felix.dependencymanager" system property. In this case, you also need to set
+     * the "org.apache.felix.dependencymanager.parallel=true" system property. When doing so:
+     * <p><ul>
+     * <li> All Dependency Manager
+     * <li>Activators will then be handled concurrently, except if they explicitly invoke setThreadPool(null)
+     * </ul>
      */
     public DependencyManager setThreadPool(Executor threadPool) {
         m_threadPool = threadPool;
+        m_setThreadPoolMethodCalled = true;
         return this;
     }
 
@@ -702,7 +712,22 @@ public class DependencyManager {
         }
     }
     
+    /**
+     * Determine if the component scheduler should be used. The scheduler is used when the {@link #PARALLEL} system
+     * property is set to "true" *AND* when the {@link #setThreadPool(Executor)} method has never been invoked.
+     * 
+     * When used, the scheduler will bufferize all activated DM components until a threadpool with a
+     * {@link #THREADPOOL} service property is registered in the OSGi registry. And at the point where the threadpool
+     * comes in, then all bufferized components will be activated using that threadpool.
+     * This simple mechanism allows to avoid to use a start level service in order to wait for the threadpool before
+     * activating any DM components.
+     * 
+     * Notice that if the {@link #PARALLEL} system property is configured, you can call {@link #setThreadPool(Executor)}
+     * with a null parameter: This will ensure that the component won't be handled in parallel, even if a threadpool is
+     * registered in the service registry.
+     * @return true if the component scheduler should be used, false if not.
+     */
     private boolean useComponentScheduler() {
-        return m_threadPool == null && "true".equalsIgnoreCase(m_context.getProperty(DependencyManager.PARALLEL));
+        return ! m_setThreadPoolMethodCalled && "true".equalsIgnoreCase(m_context.getProperty(DependencyManager.PARALLEL));      
     }
 }