On 5/28/20 7:09 PM, Han Zhou wrote: > > > On Thu, May 28, 2020 at 5:32 AM Dumitru Ceara <dce...@redhat.com > <mailto:dce...@redhat.com>> wrote: >> >> Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3 >> (i.e., "monitor_cond_since" method) with the initial monitor condition >> MC1. >> >> Assuming the following two transactions are executed on the >> ovsdb-server: >> TXN1: "insert record R1 in table T1" >> TXN2: "insert record R2 in table T2" >> >> If the client's monitor condition MC1 for table T2 matches R2 then the >> client will receive the following update3 message: >> method="update3", "insert record R2 in table T2", last-txn-id=TXN2 >> >> At this point, if the presence of the new record R2 in the IDL triggers >> the client to update its monitor condition to MC2 and add a clause for >> table T1 which matches R1, a monitor_cond_change message is sent to the >> server: >> method="monitor_cond_change", "clauses from MC2" >> >> In normal operation the ovsdb-server will reply with a new update3 >> message of the form: >> method="update3", "insert record R1 in table T1", last-txn-id=TXN2 >> >> However, if the connection drops in the meantime, this last update might >> get lost. >> >> It might happen that during the reconnect a new transaction happens >> that modifies the original record R1: >> TXN3: "modify record R1 in table T1" >> >> When the client reconnects, it will try to perform a fast resync by >> sending: >> method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2 >> >> Because TXN2 is still in the ovsdb-server transaction history, the >> server replies with the changes from the most recent transactions only, >> i.e., TXN3: >> result="true", last-txbb-id=TXN3, "modify record R1 in table T1" >> >> This causes the IDL on the client in to end up in an inconsistent >> state because it has never seen the update that created R1. >> >> Such a scenario is described in: >> https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22 >> >> To avoid this issue, the IDL will now maintain (up to) 3 different >> types of conditions for each DB table: >> - new_cond: condition that has been set by the IDL client but has >> not yet been sent to the server through monitor_cond_change. >> - req_cond: condition that has been sent to the server but the reply >> acknowledging the change hasn't been received yet. >> - ack_cond: condition that has been acknowledged by the server. >> >> Whenever the IDL FSM is restarted (e.g., voluntary or involuntary >> disconnect): >> - if there is a known last_id txn-id the code ensures that new_cond >> will contain the most recent condition set by the IDL client >> (either req_cond if there was a request in flight, or new_cond >> if the IDL client set a condition while the IDL was disconnected) >> - if there is no known last_id txn-id the code ensures that ack_cond will >> contain the most recent conditions set by the IDL client regardless >> whether they were acked by the server or not. >> >> When monitor_cond_since/monitor_cond requests are sent they will >> always include ack_cond and if new_cond is not NULL a follow up >> monitor_cond_change will be generated afterwards. >> >> On the other hand ovsdb_idl_db_set_condition() will always modify new_cond. >> >> This ensures that updates of type "insert" that happened before the last >> transaction known by the IDL but didn't match old monitor conditions are >> sent upon reconnect if the monitor condition has changed to include them >> in the meantime. >> >> CC: Han Zhou <hz...@ovn.org <mailto:hz...@ovn.org>> >> Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection >> reset.") >> Signed-off-by: Dumitru Ceara <dce...@redhat.com <mailto:dce...@redhat.com>> >> --- >> lib/ovsdb-idl-provider.h | 8 ++ >> lib/ovsdb-idl.c | 167 >> ++++++++++++++++++++++++++++++++++++++++------ >> tests/ovsdb-idl.at <http://ovsdb-idl.at> | 56 +++++++++++++++ >> 3 files changed, 206 insertions(+), 25 deletions(-)
> Acked-by: Han Zhou <hz...@ovn.org <mailto:hz...@ovn.org> Thanks! Applied to master and backported down to 2.12. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev