Operating System: All
Platform: All

https://git.opendaylight.org/gerrit/#/c/19360/

Hi Kamal,

you have right, a tx chain fail could bring a lot of problems. But a queue is holding the operation ordering in general. So please try to thing about next scenario (e.g. device are quickly connect/disconnect, so you are able to add bad statistics from disconnected device to new connected device - because we lost the ordering).

So could we submit add/remove node as own tx commit ?
I mean, we could submit tx before every add/remove node operation, wait for result and submit every add/remove like separate submit. But we have to take out all add/remove node operation in cleanDataStoreOperQueue method and we have to try to send it again in same order.

Hi Vaclav,

I guess writing of stale-stat operations is an issue we still have, since inventory-manager processes the node-removed instantly and stats-manager processes it later. So for that brief period, we do see stale stats.

I see it as below: we have 2 managers writing to operational. Inv and stats. And i feel there should not be a delay in both of these managers processing the nodeadded and node-removed. As a delay causes problems.
How to handle the stale stat operations, is a design issue.
May be we can generate a uid when a node gets added to the stats and we can associate that uid to the stat-ds-operation and feed it to the queue. On removal if the uid is not the one in the nodecollector map, it is a stale operation to be ignored. There can be many design solutions to figure out the stale operations.

In short, i dont see a value add in queueing the node-added and removed as part of the other non-priority stat operations.

Hi Vaclav,

I have added a simple fix to mark stat operations via UUIDs to ignore stale operations.

https://git.opendaylight.org/gerrit/#/c/19360/

Let me know if this addresses the issue.

Thanks
Kamal