When processing statistics responses from switches, the openflow plugin executes in parallel delete old flows and write new flows. This means flows could be deleted if the delete actions happens after the write action.

In order to update flow stats, the Openflow plugin makes a request for stats to connected switches.

When the Openflow plugin receives a response it attempts to update the flow stats in the operational datastore. The intended logic is as follows:

1) Delete existing flows
2) Write new flows

There are two scenarios where there is an issue in the current code:

1) Handling the update of stats

Both the delete and write actions were being executed in the background using 'futures'.
The problem is that it is possible for the thread writing the flows, to execute before the thread which deletes the flows. The impact of this, is that flows are deleted from the table. This behaviour is more obvious in a multi-threaded CPU environment, or dual core systems where the threads.

To fix the issue, the delete operation should not be executed in the background, instead it should be executed by the currently running thread immediately, before creating futures to perform the writes. This guarantees the order of execution.

2) Handling a multi-part response.

The same logic is used as above. But in addition, the writes must only be committed once all part of the multi-part have been executed.