[NETCONF-87] default-request-timeout-millis ignored for netconf device Created: 19/Oct/15  Updated: 15/Mar/19  Resolved: 13/Jan/16

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

Type: Bug
Reporter: Michal Rehak Assignee: Jakub Morvay
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 4496

 Description   

When creating mount point for netconf device according to
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_Additional_Netconf_Connectors_While_the_Controller_is_Running

then the default value for default-request-timeout-millis is 60k. This can be confirmed in DS/operational.

But if I add following to the input and POST it into DS/config:
<max-connection-attempts xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">3</max-connection-attempts>
<between-attempts-timeout-millis xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">2000</between-attempts-timeout-millis>
<connection-timeout-millis xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">10000</connection-timeout-millis>
<default-request-timeout-millis xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">10000</default-request-timeout-millis>

then it gets correctly reflected in DS/operational but it still takes 60 seconds till the connection times out and so the whole connection ends up with failure after 205 seconds.

Is this the right parameter to control connection timeout? If not, what is the recommended way of setting up shorter connection timeout?

 Comments   
Comment by Jakub Morvay [ 12/Jan/16 ]

I am not able to reproduce this bug. All connection related configuration parameters work for me correctly.

I tried connecting to closed port on a device, to a device that does not advertise hello message, to a device that has a slow SSH server, but I did not encounter described behaviour.

More detailed description of used setting is needed to reproduce this bug.

Comment by Alexis de Talhouët [ 12/Jan/16 ]

It is really easy for me to reproduce, and here is my setup:

I have embedded devices running confd, wired to a switch. The switch is providing the network.
I put down the internet port of the switch (thus netconf devices doesn't have internet access anymore), I perform a get on a netconf device's schema, the operation will hang for a while before eventually fail.

Using this default-request-timeout-millis should fail whatever RPCs after the desired delay, but it's not working.

Comment by Jakub Morvay [ 13/Jan/16 ]

After discussion with Alexis, the bug he can reproduce is not same as this one. He opened new case for his scenario https://bugs.opendaylight.org/show_bug.cgi?id=4940.

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