Revert "jsonrpc-server: Add test for disconnecting connections with too long queues."
authorBen Pfaff <blp@nicira.com>
Wed, 2 Apr 2014 21:22:25 +0000 (14:22 -0700)
committerBen Pfaff <blp@nicira.com>
Thu, 3 Apr 2014 14:53:38 +0000 (07:53 -0700)
This reverts commit 631583739f9aec55d4cbe25fb856143ccde48ab6.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  An upcoming patch implements this new way.  This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
tests/ovsdb-server.at

index 0cc4375..aee6f77 100644 (file)
@@ -38,8 +38,6 @@ cat stdout >> output
 
 EXECUTION_EXAMPLES
 \f
-AT_BANNER([ovsdb-server miscellaneous features])
-
 AT_SETUP([truncating corrupted database log])
 AT_KEYWORDS([ovsdb server positive unix])
 OVS_RUNDIR=`pwd`; export OVS_RUNDIR
@@ -664,89 +662,6 @@ _uuid                                name  number
 ], [], [test ! -e pid || kill `cat pid`])
 OVSDB_SERVER_SHUTDOWN
 AT_CLEANUP
-
-AT_SETUP([ovsdb-server connection queue limits])
-OVS_LOGDIR=`pwd`; export OVS_LOGDIR
-OVS_RUNDIR=`pwd`; export OVS_RUNDIR
-ON_EXIT([kill `cat *.pid`])
-
-# The maximum socket receive buffer size is important for this test, which
-# tests behavior when the receive buffer overflows.
-if test -e /proc/sys/net/core/rmem_max; then
-    # Linux
-    rmem_max=`cat /proc/sys/net/core/rmem_max`
-elif rmem_max=`sysctl -n net.inet.tcp.recvbuf_max 2>/dev/null`; then
-    : # FreeBSD
-else
-    # Don't know how to get maximum socket receive buffer on this OS
-    AT_SKIP_IF([:])
-fi
-# Calculate the total amount of data we need to queue: rmem_max in the
-# kernel plus 1024 kB in jsonrpc-server sending userspace (see default
-# backlog_threshold in ovsdb_jsonrpc_session_create() in
-# jsonrpc-server.c).
-queue_size=`expr $rmem_max + 1024 \* 1024`
-echo rmem_max=$rmem_max queue_size=$queue_size
-
-# Each flow update message takes up at least 48 bytes of space in queues
-# and in practice more than that.
-n_msgs=`expr $queue_size / 48`
-echo n_msgs=$n_msgs
-
-# Start an ovsdb-server with the vswitchd schema.
-OVSDB_INIT([db])
-AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --log-file --remote=punix:socket db],
-  [0], [ignore], [ignore])
-
-# Executes a pair of transactions that add a bridge with 100 ports,
-# and then deletes that bridge.  Each of these transactions yields
-# a monitor update about 25 kB in size.
-trigger_big_update () {
-    ovs-vsctl --db=unix:socket --no-wait -- add-br br0 $add
-    ovs-vsctl --db=unix:socket --no-wait -- del-br br0
-}
-add_ports () {
-    for j in `seq 1 100`; do
-        printf " -- add-port br0 p%d" $j
-    done
-}
-add=`add_ports`
-
-AT_CAPTURE_FILE([ovsdb-client.out])
-AT_CAPTURE_FILE([ovsdb-client.err])
-
-# Start an ovsdb-client monitoring all changes to the database,
-# make it block to force the buffers to fill up, and then execute
-# enough transactions that ovsdb-server disconnects it.
-AT_CHECK([ovsdb-client --detach --no-chdir --pidfile monitor unix:socket ALL >ovsdb-client.out 2>ovsdb-client.err])
-AT_CHECK([ovs-appctl -t ovsdb-client ovsdb-client/block])
-for i in `seq 1 100`; do
-    echo "blocked update ($i of 100)"
-    trigger_big_update
-done
-AT_CHECK([ovs-appctl -t ovsdb-client ovsdb-client/unblock])
-
-# Make sure that ovsdb-server disconnected the client and
-# that the client exited as a result.
-if grep "bytes backlogged but a complete replica would only take [[0-9]]* bytes, disconnecting" ovsdb-server.log; then
-    :
-else
-    AT_FAIL_IF([:])
-fi
-OVS_WAIT_WHILE([test -e ovsdb-client.pid])
-
-# Start an ovsdb-client monitoring all changes to the database,
-# without making it block, and then execute the same transactions that
-# we did before.  This time the client should not get disconnected.
-AT_CHECK([ovsdb-client --detach --no-chdir --pidfile monitor unix:socket ALL >ovsdb-client.out 2>ovsdb-client.err])
-for i in `seq 1 100`; do
-    echo "unblocked update ($i of 100)"
-    trigger_big_update
-
-    # Make sure that ovsdb-client gets enough CPU time to process the updates.
-    ovs-appctl -t ovsdb-client version > /dev/null
-done
-AT_CLEANUP
 \f
 AT_BANNER([OVSDB -- ovsdb-server transactions (SSL IPv4 sockets)])