Further to the description, we looked at the RFC to see if there is any standard way. But it does not currently define a way to only notify with no data. However, it does allow a query param to be vendor specific - https://tools.ietf.org/html/rfc8040#section-4.8.

If vendors define additional query parameters, they SHOULD use a
 prefix (such as the enterprise or organization name) for query
 parameter names in order to avoid collisions with other parameters.

rovarga, tcere, could you comment on this use case and take a look at the review submitted please?

"however the data underneath was quite huge, thereby causing the heap running over and the controller crashing in response to lot of changes" – this looks like the core of the issue, shouldn't that be fixed?

Note that the proposed notify-get mechanics is subject to races and it is not explained anywhere.

rovarga I agree that the ideal solution is to fix the heap running over. But this patch at least gives a reasonable workaround for consumers to continue to use websockets in such a loaded system. Also I concur we need to open a ticket to fully fix the issue. nikhil.soni.lumina can you add that with the appropriate summary and link it here so that it mentions the details of the overrun that we observe and in what conditions?

rovarga
Usecase - If a client what to listen via websocket on any changes happens in the leaf, an the leaf is inside List which contains hundreds leaf object.
If any change happens in the list then websocket returns all list data instead of one particular changed leaf which can be huge data.

Topology Example data -
{
"topology": [
{
"topology-id": "1",
"default": "true",
"topology-name": "1",
"node": [

.....thousands of nodes
]
}
in above example if any change happens in one node which is inside in "node" list then all thousands of node with data come in websocket which creates heap memory issue in client side.