On 9/12/23 20:10, Han Zhou wrote: > Thanks Ilya! > > On Fri, Sep 8, 2023 at 7:18 PM Ilya Maximets <[email protected] > <mailto:[email protected]>> wrote: >> >> While sending a reply to the monitor_cond_since request, server >> includes the last transaction ID. And it sends new IDs with each >> subsequent update. Current implementation doesn't use the one >> supplied with a monitor reply, and only takes into account IDs >> provided with monitor updates. That may cause various issues: >> >> 1. Performance: During initialization, the last-id is set to zero. >> If re-connection will happen after receiving a monitor reply, >> but before any monitor update, the client will send a new >> monitor request with an all-zero last-id and will re-download >> the whole database again. >> >> 2. Data inconsistency: Assuming one of the clients sends a >> transaction, but our python client disconnects before receiving >> a monitor update for this transaction. The las-id will point > > nit: s/las-id/last-id > > This example clearly shows the problem, but I think it may be even more > simplified: the client doesn't have to send a transaction to hit the problem. > If there are any transactions (sent by any clients) committed to the DB > between the disconnection and reconnection of the client, then there will be > such an inconsistency problem if a second disconnection (and later reconnect > again) happens immediately after receiving the monitor reply.
That's true. I tried to highlight this possibility by using words "one of the clients" vs "our python client". But maybe that didn't work as well as I hoped. :) > Acked-by: Han Zhou <[email protected] <mailto:[email protected]>> Thanks, Han and Simon! I fixed the typo and applied the patch. Also backported down to 2.17. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
