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 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/rconn.c b/lib/rconn.c
index d7bb0be..4922a5c 100644
--- a/lib/rconn.c
+++ b/lib/rconn.c
@@ -513,8 +513,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 {
@@ -545,6 +558,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.2.5
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
