Otherwise, if a monitor connection happens to be talking to a (misguided?)
peer that sends it messages, such as replies to what the peer perceives as
echo requests meant for it, then the peer will eventually hang trying to
send data because the monitor connection never sinks it.
Signed-off-by: Ben Pfaff <b...@nicira.com>
---
lib/rconn.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/lib/rconn.c b/lib/rconn.c
index 5d7595f..8962fe2 100644
--- a/lib/rconn.c
+++ b/lib/rconn.c
@@ -497,8 +497,21 @@ rconn_run(struct rconn *rc)
if (rc->vconn) {
vconn_run(rc->vconn);
}
- for (i = 0; i < rc->n_monitors; i++) {
+ for (i = 0; i < rc->n_monitors; ) {
+ struct ofpbuf *msg;
+ int retval;
+
vconn_run(rc->monitors[i]);
+
+ /* Drain any stray message that came in on the monitor connection. */
+ retval = vconn_recv(rc->monitors[i], &msg);
+ if (!retval) {
+ ofpbuf_delete(msg);
+ } else if (retval != EAGAIN) {
+ close_monitor(rc, i, retval);
+ continue;
+ }
+ i++;
}
do {
@@ -529,6 +542,7 @@ rconn_run_wait(struct rconn *rc)
}
for (i = 0; i < rc->n_monitors; i++) {
vconn_run_wait(rc->monitors[i]);
+ vconn_recv_wait(rc->monitors[i]);
}
timeo = timeout(rc);
--
1.7.10.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
