[NETCONF-1232] Eliminate netconf-config artifact Created: 24/Jan/24  Updated: 26/Jan/24  Resolved: 26/Jan/24

Status: Resolved
Project: netconf
Component/s: netconf-nb, netconf-topology
Affects Version/s: None
Fix Version/s: 7.0.0

Type: Task Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to NETCONF-1233 Blocking call during NetconfDeviceSch... In Progress
relates to CONTROLLER-2092 Remove odl-controller-exp-netty-config Resolved

 Description   

netconf-config hosts three components:

  1. global-netconf-ssh-scheduled-executor (a ScheduledThreadPool)
  2. global-netconf-processing-executor (a ThreadPool)
  3. plus the thread factory to go with that

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.

Eliminate this component by:

  1. moving the ScheduleThreadPool to netconf-nb, ditching the dependency on controller in the process
  2. creating dedicated thread pools for each of the topology applications with its own config, perhaps with some tooling provided by topology.spi

This will render the thread factory superfluous, as each pool will have its proper name.



 Comments   
Comment by Robert Varga [ 26/Jan/24 ]

So the ScheduledThreadPool can be completely inlined as a single-threaded executor.
The global executor ends up as NetconfTopologySchemaAssember – which does not leak its internal executor and provides a place where we want to meed netconf-client-mdsal requirements.

Generated at Wed Feb 07 20:16:59 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.