Operating System: All
Platform: All

Do you use this setup https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf:Change_event_notification_subscription ?

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.

Another, possibly better alternative is to split the act of defining the notification stream and the act of subscribing the stream.

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 – hence each websocket client will have its own DataTreeChangeListener.

This also means that such a stream does not have the RFC5277 replaySupport capability (e.g. replaySupport is always false).

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.