basic openflow network breaks after short cbench test with l2switch feature installed

TL;DR using a larger number of switches in a cbench test breaks the openflow-ness such
that a simple mininet network will not work.

Test Details:

Setup: install these features:

• odl-l2switch-all
• odl-l2switch-switch-rest
• odl-l2switch-switch-ui
• odl-dlux-all

Steps:
1) start small mininet topo (tree,1,3) and verify successful pingall, then quit
2) send brief cbench test (-m 5000 -M 10000 -s 64 -l 2 -t)
3) repeat step 1, but pingall fails and switches are not learned

Notes:

in step 1, the switch is learned and it is removed when mininet is done.

after step 2, there are leftover switches in the operational store.

once this state is seen, the logout (exiting karaf console) process takes a very long time
(or never exits), and I just kill the java process so I don’t have to wait.
see at the end of the logs here: http://pastebin.com/Kj4hdves

The cbench test simulates X openflow 1.0 switches all connecting. When X == 32 this
problem doesn’t always happen, but maybe on the second iteration of steps 1-3. With
64 it looks like it happens every time.

I took a packet capture of the mininet network connecting in the problem state and the
handshake looks ok. After the final ACK is given by the controller to the MULTIPART
REPLY the only traffic is originating from the switch (e.g. port status msg, or packet-in’s
triggered by data plane traffic — pingall). In a working environment we’ll see LLDP
packet out learning, default flows being pushed, etc. None of that is happening
here.