| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support the new monitor method monitor_cond_since so that a client
can request monitoring start from a specific point instead of always
from beginning. This will reduce the cost at scenarios when server
is restarted/failed-over but client still has all existing data. In
these scenarios only new changes (and in most cases no change) needed
to be transfered to client. When ovsdb-server restarted, history
transactions are read from disk file; when ovsdb-server failed over,
history transactions exists already in the memory of the new server.
There are situations that the requested transaction may not be found.
For example, a transaction that is too old and has been discarded
from the maintained history list in memory, or the transactions on
disk has been compacted during ovsdb compaction. In those situations
the server fall backs to transfer all data start from begining.
For more details of the protocol change, see
Documentation/ref/ovsdb-server.7.rst.
This change includes both server side and ovsdb-client side changes
with the new protocol. IDLs using this capability will be added in
future patches.
Now the feature takes effect only for cluster mode of ovsdb-server,
because cluster mode is the only mode that supports unique transcation
uuid today. For other modes, the monitor_cond_since always fall back
to transfer all data with found = false. Support for those modes can
be added in the future.
Signed-off-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current ovsdb monitor maintains its own transaction version through an
incremental integer and use it to identify changes starting from different
version, and also use it to figure out if each set of changes should be
flushed. In particular, it uses number 0 to represent that the change set
contains all data for initial client population. It is a smart way but it
prevents further extension of the monitoring mechanism to support future use
case for clients to request changes starting from a given history point. This
patch refactors the structures so that change sets are referenced directly
through the pointer. It uses additional members such as init_change_set,
new_change_set to indicates the specific change set explicitely, instead of
through calculated version numbers based on implicite rules.
At the same time, this patch provides better encapsulation for change set
(composed of data in a list of tables), while still allowing traversing
across change sets for a given table.
Signed-off-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Ommiting the parameter names in prototypes, as suggested by coding
style: Omit parameter names from function prototypes when the names
do not give useful information.
Adjust orders of parameters as suggested by coding style.
Signed-off-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OVSDB conditional monitor implementation allows many clients
to share same copy of monitored data if the clients are sharing
same tables and columns being monitored, while they can have
different monitor conditions. In monitor conditions they can
have different columns which can be different from the columns
being monitored. So the struct ovsdb_monitor_table maintains the
union of the all the columns being used in any conditions.
The problem of the current implementation is that for each change
set generated, it doesn't maintain any metadata for the number of
columns for the data that has already populated in it. Instead, it
always rely on the n_columns field of the struct ovsdb_monitor_table
to manipulate the data. However, the n_columns in struct
ovsdb_monitor_table can increase (e.g. when a client changes its
condition which involves more columns). So it can result in that
the existing rows in a change set with N columns being later processed
as if it had more than N columns, typically, when the row is freed.
This causes the ovsdb-server crashing (see an example of the
backtrace).
The patch fixes the problem by maintaining n_columns for each
change set, and added a test case which fails without the fix.
(gdb) bt
at lib/ovsdb-data.c:1031
out>, mt=<optimized out>) at ovsdb/monitor.c:320
mt=0x1e7b940) at ovsdb/monitor.c:333
out>, transaction=<optimized out>) at ovsdb/monitor.c:527
initial=<optimized out>, cond_updated=cond_updated@entry=false,
unflushed_=unflushed_@entry=0x20dae70,
condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156
(m=m@entry=0x20dae40, initial=initial@entry=false) at
ovsdb/jsonrpc-server.c:1655
at ovsdb/jsonrpc-server.c:1729
ovsdb/jsonrpc-server.c:551
ovsdb/jsonrpc-server.c:586
ovsdb/jsonrpc-server.c:401
exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0,
unixctl=0x1e7a560, all_dbs=0x7ffdb947f800,
jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209
Signed-off-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
With this change, "ovsdb-client convert" can be used to convert a database
from one schema to another without taking the database offline.
This can be useful to minimize downtime for a database during a software
upgrade.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, OVSDB distinguished "monitors", which are associated with OVSDB
JSON-RPC client sessions and allow clients to find out about database
changes, from "replicas", which are associated with databases and also find
out about database changes and act on them in some way. Now that
committing to disk has been broken into a separate concept, there is a
one-to-one and "onto" relationship between monitors and replicas: every
monitor M has a replica R and R is associated with M as well. It's easier
if we just treat them as a single entity, and that's what this commit
implements.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, ovsdb-server has internally chained a list of replicas from each
database. Whenever ovsdb_txn_commit() commits a transaction, it passes the
transaction to each replica. The first replica, which is always the disk
file that stores the database, is special because it is the only replica
that can report an error and thereby abort the transaction. This is a very
special property that genuinely distinguishes this first replica from the
others on the chain. This commit breaks that first replica out as a
separate kind of entity that is not on the list of replicas. When later
commits add support for clustering, there will only be more and more
special cases for the "first replica", so it makes sense to distinguish it
this way.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
This removes n_true_cnd from struct ovsdb_monitor_session_condition.
It was an "optimization" that is not part of any inner loop, but
make the code harder to reason about.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
Acked-by: Liran Schour <lirans@il.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of ovsdb-server caches only non-conditional
monitors, that is, monitors for every table row, not those that monitor
only rows that match some condition. To figure out which monitors are
conditional, the code track the number of tables that have conditions that
are uniformly true (cond->n_true_cnd) and compares that against the number
of tables in the condition (shash_count(&cond->tables)). If they are the
same, then every table has (effectively) no condition, and so
cond->conditional is set to false.
However, the implementation was buggy. The function that adds a new
table condition, ovsdb_monitor_table_condition_create(), only updated
cond->conditional if the table condition being added was true. This is
wrong; only adding a non-true condition can actually change
cond->conditional. This commit fixes the problem by always recalculating
cond->conditional.
The most visible side effect of cond->conditional being true when it
should be false, as caused by this bug, was that conditional monitors were
being mixed with unconditional monitors for the purpose of caching. This
meant that, if a client requested a conditional monitor that was the
same as an unconditional one, except for the condition, then the client
would receive the cached data previously sent for the unconditional one.
This commit fixes the problem.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
Acked-by: Liran Schour <lirans@il.ibm.com>
|
| |
|
|
|
|
|
|
|
|
| |
I believe that this would trigger an ovsdb-server crash if a client created
a plain RFC 7047 "monitor" and later attempted to update its condition.
Found by Coverity.
Reported-at: https://scan3.coverity.com/reports.htm#v16889/p10449/fileInstanceId=14763017&defectInstanceId=4305336&mergedDefectId=180412
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The newly added replication logic makes it possible for a monitor to
receive delete and insertion of the same row back to back, which
was not possible before. Add logic (and comment) to handle this
case to avoid follow crash reported by Valgrind:
#0 0x0000000000453edd in ovsdb_datum_compare_3way
(a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1626
#1 0x0000000000453ea4 in ovsdb_datum_equals
(a=0x5efbe60, b=0x0, type=0x5e6a848) at lib/ovsdb-data.c:1616
#2 0x000000000041b651 in update_monitor_row_data
(mt=0x5eda4a0, row=0x5efbe00, data=0x0) at ovsdb/monitor.c:310
#3 0x000000000041ed14 in ovsdb_monitor_changes_update
(old=0x0, new=0x5efbe00, mt=0x5eda4a0, changes=0x5ef7180)
at ovsdb/monitor.c:1255
#4 0x000000000041f12e in ovsdb_monitor_change_cb
(old=0x0, new=0x5efbe00, changed=0x5efc218, aux_=0xffefff040)
at ovsdb/monitor.c:1339
#5 0x000000000042ded9 in ovsdb_txn_for_each_change
(txn=0x5efbd90, cb=0x41ef50 <ovsdb_monitor_change_cb>,
aux=0xffefff040) at ovsdb/transaction.c:906
#6 0x0000000000420155 in ovsdb_monitor_commit
(replica=0x5eda2c0, txn=0x5efbd90, durable=false)
at ovsdb/monitor.c:1553
#7 0x000000000042dc04 in ovsdb_txn_commit_
(txn=0x5efbd90, durable=false) at ovsdb/transaction.c:868
#8 0x000000000042ddd4 in ovsdb_txn_commit (txn=0x5efbd90, durable=false)
at ovsdb/transaction.c:893
#9 0x0000000000422e0c in process_notification
(table_updates=0x5efad10, db=0x5e6bd40) at ovsdb/replication.c:575
#10 0x0000000000420ff3 in replication_run () at ovsdb/replication.c:184
#11 0x0000000000405cc8 in main_loop
(jsonrpc=0x5e67770, all_dbs=0xffefff3a0, unixctl=0x5ebd980,
remotes=0xffefff360, run_process=0x0, exiting=0xffefff3c0,
is_backup=0xffefff2de) at ovsdb/ovsdb-server.c:198
#12 0x0000000000406edb in main (argc=1, argv=0xffefff550)
at ovsdb/ovsdb-server.c:429
Reported-by: Joe Stringer <joe@ovn.org>
Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079315.html
Reported-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Reported-at: http://openvswitch.org/pipermail/dev/2016-September/079586.html
Co-authored-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
Found by inspection.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
By placing these nodes at the start of their respective structures,
several "possibly lost" warnings from valgrind are silenced.
Fixes: 60e0cd041958 ("ovsdb: Replication usability improvements")
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Destroy shash on destroy of session's condition structure.
Reported here: http://openvswitch.org/pipermail/dev/2016-July/075968.html
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: William Tu <u9012063@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To easily allow both in- and out-of-tree building of the Python
wrapper for the OVS JSON parser (e.g. w/ pip), move json.h to
include/openvswitch. This also requires moving lib/{hmap,shash}.h.
Both hmap.h and shash.h were #include-ing "util.h" even though the
headers themselves did not use anything from there, but rather from
include/openvswitch/util.h. Fixing that required including util.h
in several C files mostly due to OVS_NOT_REACHED and things like
xmalloc.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Optimize ovsdb_condition_match_any_clause() to be in O(#columns in condition)
and not O(#clauses) in case condition's caluses function is boolean or "==".
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
ovsdb-server now accepts "monitor_cond_change" request. After conditions change
we compose update notification according to the current state of the
database without using a change list before sending reply to the monitor_cond_change
request.
Sees ovsdb-server (1) man page for details of monitor_cond_change.
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hold session's conditions in ovsdb_monitor_session_condition. Pass it
to ovsdb_monitor for generating "update2" notifications.
Add functions that can generate "update2" notification for a
"monitor_cond" session.
JSON cache is enabled only for session's with true condition only.
"monitor_cond" and "monitor_cond_change" are RFC 7047 extensions
described by ovsdb-server(1) manpage.
Performance evaluation:
OVN is the main candidate for conditional monitoring usage. It is clear that
conditional monitoring reduces computation on the ovn-controller (client) side
due to the reduced size of flow tables and update messages. Performance
evaluation shows up to 75% computation reduction.
However, performance evaluation shows also a reduction in computation on the SB
ovsdb-server side proportional to the degree that each logical network is
spread over physical hosts in the DC. Evaluation shows that in a realistic
scenarios there is a computation reduction also in the server side.
Evaluation on simulated environment of 50 hosts and 1000 logical ports shows
the following results (cycles #):
LN spread over # hosts| master | patch | change
-------------------------------------------------------------
1 | 24597200127 | 24339235374 | 1.0%
6 | 23788521572 | 19145229352 | 19.5%
12 | 23886405758 | 17913143176 | 25.0%
18 | 25812686279 | 23675094540 | 8.2%
24 | 28414671499 | 24770202308 | 12.8%
30 | 31487218890 | 28397543436 | 9.8%
36 | 36116993930 | 34105388739 | 5.5%
42 | 37898342465 | 38647139083 | -1.9%
48 | 41637996229 | 41846616306 | -0.5%
50 | 41679995357 | 43455565977 | -4.2%
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit allows to add unmonitored columns to a monitored table
due to condition update.
It will be used to evaluate conditions on unmonitored columns.
Update notification includes only monitored columns.
Due to the limited number of columns, we do not remove unused unmonitored
columns on condition update for code simplicity.
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Columns indexing is different in ovsdb_row then in ovsdb_monitor_row.
We need mapping between the 2 for condition evaluation.
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
Makes popping each member of the hmap a bit easier.
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
This attempts to prevent namespace collisions with other list libraries
Signed-off-by: Ben Warren <ben@skyportsystems.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
| |
Signed-off-by: Ben Warren <ben@skyportsystems.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Add the size of json cache to the data reported by ovsdb-server appctl
"memory/show" command.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When destroying an ovsdb_jsonrpc_monitor, the jsonrpc monitor still
holds a reference count to the monitors 'changes' indexed with
'unflushed' transaction id. The bug is that the reference count was
not decremented as it should in the code path.
The bug caused 'changes' that have been flushed to all jsonrpc
clients to linger around unnecessarily, occupying increasingly
large amount of memory. See "Reported-at" URL for more details.
This bug is tricky to find since the memory is not leaked; they will
eventually be freed when monitors are destroyed.
Reported-by: Lei Huang <huang.f.lei@gmail.com>
Reported-at: http://openvswitch.org/pipermail/dev/2016-March/067274.html
Signed-off-by: Andy Zhou <azhou@ovn.org>
Tested-by: Han Zhou <zhouhan@gmail.com>
Acked-by: Han Zhou <zhouhan@gmail.com>
Acked-by: Liran Schour <lirans@il.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
'prev_txn' and 'next_txn" are more confusing than 'unflushed' and
'unflushed_next'. Rename them.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Liran Schour <lirans@il.ibm.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dbmon's changes should be stored with the next transaction number,
rather than the current transaction number. This bug causes the
changes of a transaction stored in a monitor to be unnoticed by
the jsonrpc connections that is responsible for flush the monitor
content.
However, the bug was not noticed until it was exposed by a later
optimization patch: "avoid unnecessary call to ovsdb_monitor_get_update()."
The lack of optimization means that the update is still generated
when 'unflushed' equals to n_transactions + 1, which should have
indicated the monitor has been flushed already.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Liran Schour <lirans@il.ibm.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 4c2809787cdbc774 (ovsdb-monitor: add json cache) introduced
an optimization that allows jsonrpc session to share monitors.
However, the memory/show implementation was not updated to match the
implementation; it still assumes that each jsonrpc session uses its
own monitor, thus are likely to over reporting the number.
This patch fix the bug and reports the actual number of monitor used
by the ovsdb-server.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cached json objects were reused when sending notifications to
clients. This created a problem when there were different versions
of monitors coexisting. E.g. clients expecting version2 notification
would receive messages with method == "update2" but payload in
version1 format, which end up failure of processing the updates.
This patch fixes the issue by including version in cache node.
Signed-off-by: Han Zhou <zhouhan@gmail.com>
Acked-by: Andy Zhou <azhou@ovn.org>
Signed-off-by: Andy Zhou <azhou@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
Add functions that can generate "update2" notification for a
"monitor2" session. "monitor2" and "update2" are RFC 7047 extensions
described by ovsdb-server(1) manpage. See the manpage changes
for more details.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
This function will have multiple callers in later patches.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
| |
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
|
| |
|
|
|
| |
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
This function does use this parameter.
(This does not change any behavior.)
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, JSON cache is always flushed whenever the monitor receives
a transaction. This patch improves the JSON cache efficiency by only
flush the JSON cache when a transaction causes client visible
changes, avoiding unnecessary flushes.
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
| |
Some DB modification transactions won't affect the columns of a monitor.
Skip those updates.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
| |
The logic of determining row update type will be useful in the following
patch. Make it into a function.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although multiple jsonrpc monitors can share the same ovsdb monitor,
each change still needs to translated into json object from scratch.
This can be wasteful if multiple jsonrpc monitors are interested in the
same changes.
Json cache improves this by keeping an copy of json object generated
for transaction X to current transaction. When jsonrpc is interested
in a change, the cache is searched first, if an json object is found,
a copy of it is handed back, skipping the regeneration process.
Any commit to the monitor will empty the cache. This can be further
optimized to not throw away the cache if the updated tables and columns
are not being monitored.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
monitor
Store ovsdb monitor in a global hmap. If a newly created ovsdb monitor
object monitors the same tables and columns as an existing one, the
existing monitor will be reused.
With this patch, jsonrpc monitor and ovsdb monitor now have N:1 mapping.
The goals are to:
1) Reduce the cost of maintaining duplicated monitors.
2) Allow for create Json cache for the same updates. Json cache will be
introduced in the following patch.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
| |
Add ovsdb_monitor_add_jsonrpc_monitor(). This change will allow
ovsdb_monitor to be reference counted.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
| |
monitor table
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, each monitor table contains a single hmap 'changes' to
track updates. This patch introduces a new data structure
'ovsdb_monitor_changes' that stores the updates 'rows' tagged by
its first commit transaction id. Each 'ovsdb_monitor_changes' is
refenece counted allowing multiple jsonrpc_monitors to share them.
The next patch will allow each ovsdb monitor table to store a list
of 'ovsdb_monitor_changes'. This patch stores only one, same as
before.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
| |
jsonrpc_monitor_compose_update() seems to fit better than
jsonrpc_monitor_compose_table_update(), since it composes changes
from all tables. Albeit the original one is named after the
<table-updates> object described in RFC 7047.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With N:1 mappings, multiple jsonrpc server may be servicing the rpc
connection at a different pace. ovsdb-monitor thus needs to maintain
different change sets, depends on connection speed of each rpc
connections. Connections servicing at the same speed can share the
same change set.
Transaction ID is an concept added to describe the change set. One
possible view of the database state is a sequence of changes, more
precisely, commits be applied to it in order, starting from an
initial state, with commit 0. The logic can also be applied to the
jsonrpc monitor; each change it pushes corresponds to commits between
two transaction IDs.
This patch introduces transaction IDs. For ovsdb-monitor, it maintains
n_transactions, starting from 0. Each commit add 1 to the number.
Jsonrpc maintains and 'unflushed' transaction number, corresponding to
the next commit the remote has not seen. jsonrpc's job is simply to
notice there are changes in the ovsdb-monitor that it is interested in,
i.e. 'n_transactions' >= 'unflushed', get the changes in json format,
and push them to the remote site.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, each ovsdb-monitor points to a single jsonrpc_monitor object.
This means there is 1:1 relationship between them.
In case multiple jsonrpc-monitors need to monitor the same tables and
the columns within them, then can share a single ovsdb-monitor, so the
updates only needs to be maintained once.
This patch, with a few following patches, will allow for N:1 mapping
between jsonrpc-monitor and ovsdb-monitor.
Maintaining jsonrpc-monitor pointers in a linked-list is essential
in allowing N:1 mapping. The ovsdb-monitor life cycle
is now reference counted. An empty list means zero references.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Refactoring ovsdb_monitor_get_initial() to not generate JSON object.
It only collect changes within the ovsdb_monitor().
ovsdb_jsonrpc_monitor_compose_table_update() is then used to generate
JSON object.
This change will also make future patch easier.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
|
Added new files monitor.[ch] for monitor backend functions.
There is no functional changes.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
