Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle ncclient timeout exception at close. #787

Merged
merged 4 commits into from
Sep 15, 2021

Conversation

stacywsmith
Copy link
Contributor

If dev.close() is called while another RPC is still in progress,
such as might happen if dev.timeout=1, then it's possible
the dev.close() will encounter a
ncclient.operations.errors.TimeoutExpiredError exception.
Hanlde this exception and convert it to a RpcTimeoutError.

If dev.close() is called while another RPC is still in progress,
such as might happen if the dev.timeout=1, then it's possible
the dev.close() will encounter a
ncclient.operations.errors.TimeoutExpiredError exception.
Hanlde this exception and convert it to a RpcTimeoutError.
@coveralls
Copy link

coveralls commented Oct 21, 2017

Coverage Status

Coverage decreased (-0.03%) to 93.65% when pulling 29ea65d on stacywsmith:close_exception into 0ed282b on Juniper:master.

@jnpr-community-netdev
Copy link

Build finished. 730 tests run, 0 skipped, 0 failed.

@jnpr-community-netdev
Copy link

Can one of the admins verify this patch?

@jnpr-community-netdev
Copy link

Build triggered. sha1 is merged.

@jnpr-community-netdev
Copy link

Build started sha1 is merged.

@jnpr-community-netdev
Copy link

Build finished.

@vnitinv
Copy link
Contributor

vnitinv commented Jan 31, 2018

ok to test

Copy link
Contributor

@vnitinv vnitinv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good. thanks @stacywsmith

@kokel
Copy link

kokel commented Oct 18, 2018

What's the progress about this? We need this fix ...

@vnitinv
Copy link
Contributor

vnitinv commented Oct 18, 2018

@kokel @stacywsmith wondering in case of RpcTimeoutError should we be setting dev.connected to False?

@stacywsmith
Copy link
Contributor Author

@kokel @stacywsmith wondering in case of RpcTimeoutError should we be setting dev.connected to False?

No. You can't set dev.connected to False just because you received an RpcTimeoutError. The NETCONF session may still be open. It may simply be that the RPC is taking longer to execute than the allotted timeout. That doesn't necessarily mean it won't finish executing, or that the session is closed. I have seen cases where the timeout on an RPC request is intentionally set very low to ensure a "fast failure".

You could potentially catch the timeout exception inside the close() method and disconnect the underlying SSH session even though the <close-session/> RPC wasn't successfully sent/acknowledged.

@rahkumar651991 rahkumar651991 merged commit b96f116 into Juniper:master Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants