On Sat, Sep 09, 2023 at 04:18:36AM +0200, Ilya Maximets 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
> to a database state before this transaction. On re-connection,
> this last-id will be sent and the monitor reply will contain
> a diff with a new data from that transaction. But if another
> disconnection happens right after that, on second re-connection
> our python client will send another monitor_cond_since with
> exactly the same last-id. That will cause receiving the same
> set of updates again. And since it's an update2 message with
> a diff of the data, the client will remove previously applied
> result of the transaction. At this point it will have a
> different database view with the server potentially leading
> to all sorts of data inconsistency problems.
>
> Fix that by always updating the last-id from the latest monitor
> reply.
>
> Fixes: 46d44cf3be0d ("python: idl: Add monitor_cond_since support.")
> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
Acked-by: Simon Horman <ho...@ovn.org>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
