Only the time connected (if connected) or disconnected (if disconnected) is
currently reported for each manager. Change to reporting both in seconds since
the last connect and disconnect events respectively. An empty value indicates
no previous connection or disconnection.
This can help diagnose certain connectivity problems, e.g. flapping.
Requested-by: Peter Balland <peter@nicira.com>
Bug #4833.
reconnect uses the same connection state names as rconn with the exception of
the above. This commit makes their states identical, which should reduce
confusion for people debugging connection problems.
Commit a4613b01ab (ovsdb: Change the way connection duration time is reported
in Manager table.), pushed earlier today, requires this commit, so OVSDB has
been unbuildable from then to now.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
In the ovsdb-server log there are fairly continuous messages like these:
Apr 26 11:27:55|15254|reconnect|INFO|unix:/tmp/stream-unix.31734.0: connected
Apr 26 11:27:55|15255|reconnect|INFO|unix:/tmp/stream-unix.31734.0: connection dropped
Apr 26 11:28:00|15256|reconnect|INFO|unix:/tmp/stream-unix.31810.0: connecting...
Apr 26 11:28:00|15257|reconnect|INFO|unix:/tmp/stream-unix.31810.0: connected
Apr 26 11:28:00|15258|reconnect|INFO|unix:/tmp/stream-unix.31810.0: connection dropped
These just indicate that ovs-vsctl is connecting to ovsdb-server from,
for example, the "vif" script. But there's no need to log all that detail;
it's simply not useful. This commit suppresses it.
Bug #2715.
reconnect_run() returns RECONNECT_CONNECT to tell the client that it should
start a new connection. The client is then supposed to call
reconnect_connecting() to tell the FSM that it has begun a connection
attempt. However, even after reconnect_connecting() was called,
reconnect_run() continued to return RECONNECT_CONNECT on each call until
the connection succeeded or failed. This confused the jsonrpc_session
client, which expected that it would get a 0 return value from
reconnect_run() while the connection attempt was in progress. Connections
that required multiple trips through the main poll loop, e.g. for SSL
negotiation, would often get cut off to start a second connection attempt.
This commit change reconnect_run() to return RECONNECT_CONNECT only until
the client tells it that a connection is in progress, which fixes the
problem. This change entails a change to the internal details of the
reconnect FSM, so this commit also updates the reconnect tests to match.
Reported by Jeremy Stribling.
Sometimes it is useful to limit the number of connection attempts, either
from policy or because it is not possible to reconnect at all (e.g. because
a connection was accepted from a listening socket instead of made with
connect()). This commit adds that feature.
This library implements the reconnection FSM used by the "rconn" library.
Therefore, it makes sense to change rconn to use this, and I have a patch
to do that, but I am not applying it at the moment to avoid changing unrelated
code on the "db" branch.