[TOPOPROCES-83] Output topologies occassionally lack some part of themselves Created: 25/Jul/16  Updated: 19/Oct/17  Resolved: 02/Aug/16

Status: Resolved
Project: topoprocessing
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Martin Dindoffer Assignee: Tomas Vahancik
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 6263

 Description   
      • Summary ***
        The output topology may on occassion miss a termination point(s), supporting node(s), or any other item(s).
        This usually results in failing of a system test case.
      • Example ***
        An example can be seen in topoprocessing-csit-verify-1node-topology-operations job run nr. 146 [1].
        The test "Link Computation Aggregation Filtration" failed because the output topology lacked a supporting node.

Log evidence:
Trace evidence of the bug can be seen in the karaf logs.
On line 6737 of the karaf log [2] the output node:2 contains the proper amount of supporting nodes.
However, on line 6752 is the UnderlayTopologyListener processing the node:2 again for no apparent reason, only with the aforementioned supporting-node already missing.

 Comments   
Comment by Tomas Vahancik [ 26/Jul/16 ]

It seems to be a problem with synchronization. TopologyWriter may write overlaynodes in wrong order.

For example:
**Right order**
First written overlaynode in datastore has one supporting node. After that comes next node which is aggregated with the first one. So overlaynode now contains 2 supporting nodes and is written into datastore.

**Wrong order**
TopologyWriter first writes overlaynode with 2 supporting nodes and after that writes overlaynode with only one supporting node.

Comment by Andrej Záň [ 02/Aug/16 ]

Boron: https://git.opendaylight.org/gerrit/#/c/42949/3
Beryllium: https://git.opendaylight.org/gerrit/#/c/42990/1

Generated at Wed Feb 07 20:40:38 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.