[NETCONF-226] Use sal-netconf-connector to connet device costs too much time Created: 16/Jul/16  Updated: 15/Mar/19  Resolved: 19/Aug/16

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Hou Jin Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

External issue ID: 6198

 Description   

When we uses sal-netconf-connector(Lithium sr4) to connet our router device(contains 200+ yang capabilities),it costs hours to be connected. The conntroller does not support the most yang capabilities of the device, but it is blocked in

at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
at com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at com.google.common.util.concurrent.ForwardingListenableFuture.addListener(ForwardingListenableFuture.java:47)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$RecursiveSchemaSetup.setUpSchema(NetconfDevice.java:460)
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$RecursiveSchemaSetup.access$1400(NetconfDevice.java:390)
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$RecursiveSchemaSetup$1.onFailure(NetconfDevice.java:443)

it costs too many hours untill it connected at last with many source miss yang capabilities.

 Comments   
Comment by Jakub Morvay [ 19/Jul/16 ]

Hi,

Unfortunately, Lithium is not supported anymore. Can you please try this on Beryllium or Boron?

Also moving bug from controller product to netconf product here in bugzilla, since netconf is standalone project now.

Comment by Hou Jin [ 20/Jul/16 ]

We find that when a netconf device(with 200 yang capabilities that controller does not support) connected, in function onRemoteSessionUp it costs too much time in setUpSchema. It uses a recursion to check the yang capabilities of the remote device. when found a yang capability does not supported in controller it throw a MissingSchemaSourceException and remove the yang capability and recursively setUpSchema. Each check it use Futures.allAsList to check all yang capabilities so it will result 200 MissingSchemaSourceExceptions first time and 199 MissingSchemaSourceExceptions next time and ... All the time wasted in Exceptions so it costs hours to connect the device.

Comment by Rong Xu [ 22/Jul/16 ]

I try to fix the bug.

Every missing source YANG capability will throw a MissingSchemaSourceException and trigger an additional call to createSchemaContext in class RecursiveSchemaSetup.

I filter out all missing source YANG capabilities before call createSchemaContext, in order to avoid repeated call createSchemaContext too many times.

https://git.opendaylight.org/gerrit/#/c/42133/

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