Fix toward Bug 341.
Store the neighbor nodes in a HashMap indexed by the local Port ID
instead of a LinkedList.
This makes the output of the getTopoShortestPath() predictable
regardless where or when it is executed.
NOTE: This is NOT the root cause for this bug.
After some investigation, it seems that the DataPathSummary string
in the Flow vertexes in the Network MAP contains the correct
shortest path, but somehow the wm/flow/getsummary/ REST call
(method FlowManager::getAllFlowsWithoutFlowEntries()) returns
the old information.
The initial suspect is that we don't do conn.endTx(Transaction.COMMIT)
inside that method (so the returned IFlowPath object is valid),
but according to Pankaj this shouldn't be the root cause.
Investigation continues.
Reviewed by: Jono
diff --git a/src/main/java/net/floodlightcontroller/routing/TopoRouteService.java b/src/main/java/net/floodlightcontroller/routing/TopoRouteService.java
index ca8d92f..95a3b19 100644
--- a/src/main/java/net/floodlightcontroller/routing/TopoRouteService.java
+++ b/src/main/java/net/floodlightcontroller/routing/TopoRouteService.java
@@ -65,7 +65,7 @@
};
public long nodeId; // The node ID
- public LinkedList<Link> links; // The links originating from this node
+ public HashMap<Short, Link> links; // The links originating from this node
/**
* Node constructor.
@@ -74,7 +74,7 @@
*/
public Node(long nodeId) {
this.nodeId = nodeId;
- links = new LinkedList<Link>();
+ links = new HashMap<Short, Link>();
}
/**
@@ -88,7 +88,7 @@
*/
public void addNeighbor(Node neighbor, short myPort, short neighborPort) {
Link link = new Link(this, neighbor, myPort, neighborPort);
- links.add(link);
+ links.put(myPort, link);
}
};
@@ -338,7 +338,7 @@
path_found = true;
break;
}
- for (Node.Link link : nextVertex.links) {
+ for (Node.Link link : nextVertex.links.values()) {
Node child = link.neighbor;
if (! visitedSet.contains(child)) {
previousVertexMap.put(child, link);