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-2 infrautils <p>Today the controller does not have a mechanism that prevents a plugin from consuming all CPU resources thus starving other plugins, controller services, and applications. A Plugin could implement a service to throttle processing to ensure it don’t consume all CPU resources. However, this type of service is something that many plugins would utilize, and it may make sense for the Controller to provide this service.</p> <p>Operating System: All<br/> Platform: All</p> INFRAUTILS-2

Ability to control how much processing in given to a plugin

Improvement Resolved Won't Do Michael Vorburger Steve Dean Mon, 12 Jan 2015 20:15:22 +0000 Tue, 3 Apr 2018 06:27:35 +0000 Tue, 3 Apr 2018 06:27:35 +0000 Nitrogen General 0 5 <p>Would this be a resource-capping thing akin to cgroups?</p> <p>Assuming you are referring to the linux control group concept, yes, i would agree there are some similarities. What we are attempting to protect against is a situation where on server restart the controller attempts to synchronize the data from all devices specified in the /config store. This could be a large set of devices. What we want to prevent is all threads in the controller being utilized for this synchronization as they call out to plugins. Instead, we would like to have a policy to the effect, never allocate more than 2 threads to any given plugin at any given time. So that in these situations there would always be threads available to processing other traffic through the controller.</p> <p>This bug is part of the project to Move all ADSAL associated component bugs to ADSAL</p> <p>Infrautils seems like the best place for this.</p> <p>I'm struggling to how one could build something like Linux Kernel cgroups to limit an OSGi bundle's available CPU time in a Karaf JVM by a Java library such as the code in infrautils, and personally would be inclined to close this bug as RESOLVED INVALID... </p> <p>... but I don't want to close the door to anyone having any smart ideas, and time to make such a contribution - so let's leave it open, but close it in 3 months if there are no further updates with at least rough high level possible imaginable implementation ideas - hope that seems fair.</p> Development External issue ID 2575 External issue URL Issue Type Rank 0|i01mfz: