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/NETCONF-1232 netconf <p>netconf-config hosts three components:</p> <ol> <li>global-netconf-ssh-scheduled-executor (a ScheduledThreadPool)</li> <li>global-netconf-processing-executor (a ThreadPool)</li> <li>plus the thread factory to go with that</li> </ol> <p>The first is solely used in netconf-nb, the second is used by netconf-topology (and singleton and call-home). This layout is wrong, as we do not have proper task isolation and we have this shared dependency for no good reason.</p> <p>Eliminate this component by:</p> <ol> <li>moving the ScheduleThreadPool to netconf-nb, ditching the dependency on controller in the process</li> <li>creating dedicated thread pools for each of the topology applications with its own config, perhaps with some tooling provided by topology.spi</li> </ol> <p>This will render the thread factory superfluous, as each pool will have its proper name.</p> NETCONF-1232

Eliminate netconf-config artifact

Task Medium Resolved Done Robert Varga Robert Varga pt Wed, 24 Jan 2024 17:42:38 +0000 Fri, 26 Jan 2024 12:09:52 +0000 Fri, 26 Jan 2024 12:09:52 +0000 7.0.0 netconf-nb netconf-topology 0 1 <p>So the ScheduledThreadPool can be completely inlined as a single-threaded executor.<br/> The global executor ends up as NetconfTopologySchemaAssember &#8211; which does not leak its internal executor and provides a place where we want to meed netconf-client-mdsal requirements.</p> Relates NETCONF-1233 CONTROLLER-2092 Development Rank 0|i047br: