Operating System: All
Platform: All

FYI, we had much of the same concerns for the net-virt-platform code and added the threadpool service as a result.

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

Would such a thing be beneficial here?

• Rob
  .

There are few things to consider here (not necessarily blockers for
centralized pool for modules) ..

Actually, there cannot be a central threadpool for the whole system
because we have multiple components involved. By components, I mean -
Infinispan, JGroups (at least I could not notice any libraries spawning
threads internally apart from these two)

• Infinispan by itself manages its internal threadpool. These threads are
  usable for functionality like asynchronous cache-operations (putAsync,
  removeAsync etc), asynchronous cache-listener (handle notifications such
  as cache-operations entry-created, entry-evicted, entry-updated etc on per
  cache basis), asynchronous cache-manager-listener notifications (handle
  notifications such as cluster-view-changed, merge-event (instance rejoin
  after cluster split) etc)
  Of course, we do not use async support for these. But, in case, if we
  start using async option of these features of Infinispan then, threadpool
  required for this would be managed by Infinispan and we can configure
  Infinispan with the pool parameters

• JGroups internally uses threads for its own operations

Now, threadpool which we can introduce at Opendaylight platform level
would be purely for the consumption by SAL and other components.

So, whenever, we start exploiting async features of Infinispan also,
thread-budgeting must examine all threadpools involved and no of cores of
the deployed system to select suitable quantity to reduce
context-switching overheads.

Regards

Muthukumaran (Muthu)
mkothand@in.ibm.com
M : +91-9845363820
L : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)

From: bugzilla-daemon@bugs.opendaylight.org
To: Muthukumaran Kothandaraman/India/IBM@IBMIN
Date: 04/20/2013 04:42 AM
Subject: INFRAUTILS-1 Add support for a better cooperative threading
model

https://bugs.opendaylight.org/show_bug.cgi?id=11

Rob Sherwood <Rob.Sherwood@bigswitch.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |Rob.Sherwood@bigswitch.com

— Comment #2 from Rob Sherwood <Rob.Sherwood@bigswitch.com> 2013-04-19
23:13:51 UTC —
FYI, we had much of the same concerns for the net-virt-platform code and
added
the threadpool service as a result.

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

Would such a thing be beneficial here?

• Rob
  .

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 – thus the link of an example implementation.

Does that make more sense?

• Rob
  .

Hi Rob,

Sure it does make sense. For various Opendaylight components we do need a
common thread-pool for better manageability and tuning.
I only meant that this Opendaylight specific thread-pool is one among
other possible thread-pools (Infinispan + JGroups) when we consider the
whole system.

Regards

Muthukumaran (Muthu)
mkothand@in.ibm.com
M : +91-9845363820
L : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)

From: bugzilla-daemon@bugs.opendaylight.org
To: Muthukumaran Kothandaraman/India/IBM@IBMIN
Date: 04/20/2013 09:49 AM
Subject: INFRAUTILS-1 Add support for a better cooperative threading
model

https://bugs.opendaylight.org/show_bug.cgi?id=11

— Comment #4 from Rob Sherwood <Rob.Sherwood@bigswitch.com> 2013-04-20
04:20:55 UTC —
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 – thus
the
link of an example implementation.

Does that make more sense?

• Rob
  .

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL

This is probably best addressed in infrautils.

After a couple of years of experience, having global threadpools is not a good idea, as applications will end up tramping on each other.

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 less reusable outside the confines of Karaf.

The third reason is that Project Loom is bound to rather thoroughly change the way threading works – notably structured concurrency will not be using pools.

Based on these reasons I am closing this as WONTFIX.