[VOL-3242] handle each incoming messages with a go routine
Change-Id: I00ecd42b874a23e65efe740da4ea868825d6f0f1
diff --git a/VERSION b/VERSION
index e8ea05d..c813fe1 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-1.2.4
+1.2.5
diff --git a/internal/pkg/openflow/connection.go b/internal/pkg/openflow/connection.go
index 7ad6092..fd0aa48 100644
--- a/internal/pkg/openflow/connection.go
+++ b/internal/pkg/openflow/connection.go
@@ -232,7 +232,6 @@
* a message larger than this then we will have issues
*/
headerBuf := make([]byte, 8)
-
top:
// Continue until we are told to stop
for {
@@ -309,7 +308,17 @@
"device-id": ofc.DeviceID,
"header": js})
}
- ofc.parseHeader(msg)
+ /*
+ * Spawning a go routine for every incoming message removes processing ordering guarantees.
+ * Removing such guarantees puts burden on the controller to ensure the correct ordering of
+ * incoming messages and is a less optimal and safe agent implementation.
+ * This is OK for now because ONOS keeps the order guaranteed but the agent needs to avoid
+ * relying on external fairness. Particular care and attention has to be placed in flow add/delete
+ * and relative barrier requests. e.g. a flowMod will be handled in thread different from a barrier,
+ * with no guarantees of handling all messages before a barrier.
+ * A multiple queue (incoming worker and outgoing) is a possible solution.
+ */
+ go ofc.parseHeader(msg)
}
}
logger.Debugw("end-of-stream",
@@ -380,12 +389,6 @@
ofc.sendRoleSlaveError(header)
return
}
- /*
- * Not using go routine to handle flow* messages or barrier requests
- * onos typically issues barrier requests just before a flow* message.
- * by handling in this thread I ensure all flow* are handled when barrier
- * request is issued.
- */
switch header.(ofp.IFlowMod).GetCommand() {
case ofp.OFPFCAdd:
ofc.handleFlowAdd(header.(*ofp.FlowAdd))