https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/INFRAUTILS-1 infrautils <p>As it stands today, the controller does nothing to help or hinder the use of threads. Going forward, some system to more carefully manage how threads are created and scheduled is likely to help overall system performance.</p> <p>A good starting point would be to have a ThreadPoolService which OSGi bundles could depend on and then ask for new threads. The backing implementation could either just act as a blind passthrough to a java thread pool class or (in the future) could do something smart and have hierarchical thread pools with bins for containers, bundles or whatever.</p> <p>Operating System: All<br/> Platform: All</p> INFRAUTILS-1

Add support for a better cooperative threading model

Improvement Resolved Won't Do Unassigned Colin Dixon Wed, 17 Apr 2013 06:33:16 +0000 Tue, 29 Sep 2020 14:53:44 +0000 Tue, 29 Sep 2020 14:53:44 +0000 (unspecified) General 0 5 <p>FYI, we had much of the same concerns for the net-virt-platform code and added the threadpool service as a result.</p> <p><a href="https://git.opendaylight.org/gerrit/gitweb?p=net-virt-platform.git;a=blob;f=sdnplatform/src/main/java/org/sdnplatform/threadpool/IThreadPoolService.java;h=337d856fbfeefde67d3fec611ce1b885b50d6f72;hb=HEAD" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/gitweb?p=net-virt-platform.git;a=blob;f=sdnplatform/src/main/java/org/sdnplatform/threadpool/IThreadPoolService.java;h=337d856fbfeefde67d3fec611ce1b885b50d6f72;hb=HEAD</a></p> <p>Would such a thing be beneficial here?</p> <ul class="alternate" type="square"> <li>Rob<br/> .</li> </ul> <p>There are few things to consider here (not necessarily blockers for <br/> centralized pool for modules) .. </p> <p>Actually, there cannot be a central threadpool for the whole system <br/> because we have multiple components involved. By components, I mean - <br/> Infinispan, JGroups (at least I could not notice any libraries spawning <br/> threads internally apart from these two)</p> <ul class="alternate" type="square"> <li>Infinispan by itself manages its internal threadpool. These threads are<br/> usable for functionality like asynchronous cache-operations (putAsync, <br/> removeAsync etc), asynchronous cache-listener (handle notifications such <br/> as cache-operations entry-created, entry-evicted, entry-updated etc on per <br/> cache basis), asynchronous cache-manager-listener notifications (handle <br/> notifications such as cluster-view-changed, merge-event (instance rejoin <br/> after cluster split) etc)<br/> Of course, we do not use async support for these. But, in case, if we <br/> start using async option of these features of Infinispan then, threadpool <br/> required for this would be managed by Infinispan and we can configure <br/> Infinispan with the pool parameters</li> </ul> <ul class="alternate" type="square"> <li>JGroups internally uses threads for its own operations</li> </ul> <p>Now, threadpool which we can introduce at Opendaylight platform level <br/> would be purely for the consumption by SAL and other components. </p> <p>So, whenever, we start exploiting async features of Infinispan also, <br/> thread-budgeting must examine all threadpools involved and no of cores of <br/> the deployed system to select suitable quantity to reduce <br/> context-switching overheads. </p> <p>Regards</p> <p>Muthukumaran (Muthu)<br/> mkothand@in.ibm.com<br/> M : +91-9845363820<br/> L : 080-49141730</p> <p>P(existence at t) = 1- 1/P(existence at t-1)</p> <p>From: bugzilla-daemon@bugs.opendaylight.org<br/> To: Muthukumaran Kothandaraman/India/IBM@IBMIN<br/> Date: 04/20/2013 04:42 AM<br/> Subject: <a href="https://jira.opendaylight.org/browse/INFRAUTILS-1" title="Add support for a better cooperative threading model" class="issue-link" data-issue-key="INFRAUTILS-1"><del>INFRAUTILS-1</del></a> Add support for a better cooperative threading <br/> model</p> <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=11" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=11</a></p> <p>Rob Sherwood &lt;Rob.Sherwood@bigswitch.com&gt; changed:</p> <p> What |Removed |Added<br/> ----------------------------------------------------------------------------<br/> CC| |Rob.Sherwood@bigswitch.com</p> <p>&#8212; Comment #2 from Rob Sherwood &lt;Rob.Sherwood@bigswitch.com&gt; 2013-04-19 <br/> 23:13:51 UTC &#8212;<br/> FYI, we had much of the same concerns for the net-virt-platform code and <br/> added<br/> the threadpool service as a result.</p> <p><a href="https://git.opendaylight.org/gerrit/gitweb?p=net-virt-platform.git;a=blob;f=sdnplatform/src/main/java/org/sdnplatform/threadpool/IThreadPoolService.java;h=337d856fbfeefde67d3fec611ce1b885b50d6f72;hb=HEAD" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/gitweb?p=net-virt-platform.git;a=blob;f=sdnplatform/src/main/java/org/sdnplatform/threadpool/IThreadPoolService.java;h=337d856fbfeefde67d3fec611ce1b885b50d6f72;hb=HEAD</a></p> <p>Would such a thing be beneficial here?</p> <ul class="alternate" type="square"> <li>Rob<br/> .</li> </ul> <p>I'm not sure that I (or assuming Collin) meant for the whole system... really just for various components in the controller's running process &#8211; thus the link of an example implementation.</p> <p>Does that make more sense?</p> <ul class="alternate" type="square"> <li>Rob<br/> .</li> </ul> <p>Hi Rob, </p> <p>Sure it does make sense. For various Opendaylight components we do need a <br/> common thread-pool for better manageability and tuning. <br/> I only meant that this Opendaylight specific thread-pool is one among <br/> other possible thread-pools (Infinispan + JGroups) when we consider the <br/> whole system.</p> <p>Regards</p> <p>Muthukumaran (Muthu)<br/> mkothand@in.ibm.com<br/> M : +91-9845363820<br/> L : 080-49141730</p> <p>P(existence at t) = 1- 1/P(existence at t-1)</p> <p>From: bugzilla-daemon@bugs.opendaylight.org<br/> To: Muthukumaran Kothandaraman/India/IBM@IBMIN<br/> Date: 04/20/2013 09:49 AM<br/> Subject: <a href="https://jira.opendaylight.org/browse/INFRAUTILS-1" title="Add support for a better cooperative threading model" class="issue-link" data-issue-key="INFRAUTILS-1"><del>INFRAUTILS-1</del></a> Add support for a better cooperative threading <br/> model</p> <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=11" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=11</a></p> <p>&#8212; Comment #4 from Rob Sherwood &lt;Rob.Sherwood@bigswitch.com&gt; 2013-04-20 <br/> 04:20:55 UTC &#8212;<br/> I'm not sure that I (or assuming Collin) meant for the whole system... <br/> really<br/> just for various components in the controller's running process &#8211; thus <br/> the<br/> link of an example implementation.</p> <p>Does that make more sense?</p> <ul class="alternate" type="square"> <li>Rob<br/> .</li> </ul> <p>This bug is part of the project to Move all ADSAL associated component bugs to ADSAL</p> <p>This is probably best addressed in infrautils.</p> <p>After a couple of years of experience, having global threadpools is not a good idea, as applications will end up tramping on each other.</p> <p>The second reason is we want to avoid as much as possible being framework-ish – that just increases the bar for entry of fresh developers and also means our components are actually <b>less</b> reusable outside the confines of Karaf.</p> <p>The third reason is that <a href="https://wiki.openjdk.java.net/display/loom/Main" class="external-link" target="_blank" rel="nofollow noopener">Project Loom</a> is bound to rather thoroughly change the way threading works – notably structured concurrency will not be using pools.</p> <p>Based on these reasons I am closing this as WONTFIX.</p> Duplicate CONTROLLER-9 Development External issue ID 11 External issue URL Issue Type Rank 0|i01mfr: