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/OPNFLWPLUG-423 OpenFlowPlugin <p>Currently the nodeadded and node removed operations are batched along with the stat notification operations.<br/> On exception in the tx chain, all the operations in teh queue are discarded. </p> <p>This design is applicable to the stats but is not suited for node added and node removed.</p> <p>Node added and node removed should be applied directly and should not be queued.</p> <p>Issue is mostly seen with 250+ switches on a 3 node cluster.</p> <p>This might solve many issues with related to node added and node removed being submitted.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-423

StatisticsManager misses nodeadded and noderemoved operations when exceptions occur

Bug Resolved Done Kamal Rameshan Kamal Rameshan Wed, 29 Apr 2015 21:00:56 +0000 Mon, 27 Sep 2021 09:01:29 +0000 Tue, 2 Jun 2015 22:17:34 +0000 General 0 3 <p><a href="https://git.opendaylight.org/gerrit/#/c/19360/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/19360/</a></p> <p>Hi Kamal,</p> <p>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).</p> <p>So could we submit add/remove node as own tx commit ? <br/> 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.</p> <p>Hi Vaclav,</p> <p>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.</p> <p>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.<br/> How to handle the stale stat operations, is a design issue. <br/> 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.</p> <p>In short, i dont see a value add in queueing the node-added and removed as part of the other non-priority stat operations.</p> <p>Hi Vaclav,</p> <p>I have added a simple fix to mark stat operations via UUIDs to ignore stale operations.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/19360/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/19360/</a></p> <p>Let me know if this addresses the issue.</p> <p>Thanks<br/> Kamal</p> Development External issue ID 3085 External issue URL Rank 0|i03127: