[NETCONF-784] ReconnectPromise keep reconnecting after device unregistered Created: 14/Jun/21  Updated: 18/Nov/21  Resolved: 16/Sep/21

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

Type: Bug Priority: Medium
Reporter: Satoshi Fujii Assignee: Satoshi Fujii
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by NETCONF-830 Flood of "IllegalStateException: comp... Resolved
Relates
relates to NETCONF-621 Un-mounting a netconf device does not... Confirmed

 Description   

In a netconf device connection failure situation, user may unregister (unmount) the netconf device and try to re-add the device in order to recover. However netconf-connector cannot establish session and "Mount point already exists" error recorded in karaf log.

From karaf log ReconnectPromise try to reconnect again even if the device was unregistered from topology. It seems that unmounting does not clean up resources properly so an orphaned thread keeps working in background.

This issue does not always happen, but one of the reproducible case is missing certificate in keystore.

Confirmed version

  • Sodium-SR4 (embedded in ONAP Guilin)
  • Silicon-SR0

Steps to reproduce

  1. install odl-netconf and odl-restconf features
  2. register netconf device using TLS without adding certificate to keystore
  3. connection-status become 'unable-to-connect' and message is 'No keystore private key found' (expected behavior)
  4. Unregister the netconf device
  5. the device is removed from netconf-topology, but ReconnectPromise / NetconfSessionPromise remain working and keep trying to reconnect (can be seen in log)
  6. add device certificates to keystore
  7. register netconf device again
  8. connection-status is 'connecting'
  9. after that, try unregister / register more times but status never become 'connected'.
    user has to restart karaf to recover the connection.

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