https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-351 netconf <p>Current websocket mechanism has support for subscription for notifications but doesn't support unsubscribe for notifications. <br/> This is required in re-connection scenarios for example if there is a socket disconnection due to any reason.<br/> Current behavior of websocket implementation is that on the first connect of the websocket client, all the events present up to that point are sent as a create operation notifications. Subsequent re-connections do not result in notifications for those events. This will cause losing of events during the time of disconnection.<br/> To insure no event lose client should be able to "unsubscribe" for notifications and then re-subscribe and in that case all the events will be received again.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-351

Websocket implementation doesn't support unsubscribe for notifications

Bug Medium Confirmed Unresolved Unassigned Ritu Sood Thu, 23 Feb 2017 19:08:31 +0000 Mon, 4 May 2020 23:22:34 +0000 restconf-nb 0 4 <p>Do you use this setup <a href="https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf:Change_event_notification_subscription" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf:Change_event_notification_subscription</a> ?</p> <p>What we need to do here is to expose a new RPC to destroy a dynamically created notification stream. The RPC should live in sal-restconf-connector/src/main/yang/opendaylight-md-sal-remote.yang and should tear down the stream and its listener.</p> <p>Another, possibly better alternative is to split the act of defining the notification stream and the act of subscribing the stream.</p> <p>From requirements perspective it is completely fine to create-data-change-event-subscription to just set up a blank stream (which does not actually listen for data, but knows that the instance identifier is) and then start a dedicated DataTreeChangeListener when a websocket request to listen comes in &#8211; hence each websocket client will have its own DataTreeChangeListener.</p> <p>This also means that such a stream does not have the RFC5277 replaySupport capability (e.g. replaySupport is always false).</p> <p>As for lifecycle interactions, if a stream gets destroyed, we want all existing clients to finish delivering their current notification and then disconnect them. This maps to destroying the DataTreeChangeListener once it has finished whatever its current sending to the websocket.</p> Duplicate NETCONF-409 Development External issue ID 7845 External issue URL Issue Type Rank 0|i01y07: