[ovs-discuss] OVSDB transact/notify/reply ordering

Ben Pfaff blp at nicira.com
Thu Jul 10 01:25:56 UTC 2014


On Wed, Jul 09, 2014 at 05:00:55PM -0700, Chris Hydon wrote:
> On 2014-07-09 3:41 PM, Ben Pfaff wrote:
> >On Wed, Jul 09, 2014 at 02:04:00PM -0700, Chris Hydon wrote:
> >>I am part of a team developing a program that connects to a running
> >>OVSDB server via the jsonrpc interface and performs transactions. I
> >>noticed during testing that after sending a database REQUEST, if a
> >>table has a monitor active on the same socket it will receive the
> >>monitor NOTIFY before the REPLY corresponding to the REQUEST. That
> >>means if we send a transaction and wait until we receive a REPLY
> >>with matching ID, processing any monitor notifications that come in
> >>the interim, our local cache is going to be consistent with OVSDB
> >>when we're done.
> >>
> >>Can we rely on this behaviour, or is it incidental and subject to
> >>change (i.e. is it conceivable that at some point in the future the
> >>NOTIFY will arrive after the REPLY)?
> >This is more or less an accidental property of the current
> >implementation.  It has always been true, and I don't have any plan to
> >change it, but I don't think that there's a commitment to this
> >behavior.
> >
> >One property that I can solidly commit to is that any given NOTIFY
> >represents a complete transactional state of the database.  That is,
> >the database never breaks a transaction into two pieces and sends them
> >in separate notifications.  (Newer versions of ovsdb-server *will*
> >combine multiple transactions into a single notification, if the
> >database connection gets backlogged, but never splits them.)
> 
> Thanks. Follow-up question: if I issue a transaction and it
> succeeds, are all clients guaranteed to receive the same
> notification (as far as what was specified in that client's monitor
> request)? I'm considering whether the following edge case could be
> possible in the future, based on your comment about combining
> multiple transactions:
> 
> - Client A sends REQUEST 1, making update X.
> - Client A receives REPLY 1 and waits for NOTIFY of X.
> - Client B receives NOTIFY of X.
> - Client B sends REQUEST 2, making update Y.
> - Client B receives REPLY 2 and NOTIFY of Y.
> - Client A receives combined NOTIFY of X and Y.
> 
> Could that happen, or would the NOTIFY of X to A be queued at the
> same time as to B, and thus never be combined with Y?

Notifications sent to different clients can be combined differently.
Combining of notification sent to a particular client depends on whether
and when the socket buffer gets filled.  This means that it's more
likely that notifications will be combined if they are sent to a remote
client (to which there is limited bandwidth) over TCP or SSL than if
they sent to an on-box client.  In the extreme, a client that resides on
a network whose connectivity goes down for a few seconds might see all
essentially all of its transactions combined until connectivity comes
back up, whereas a client connected locally over a Unix domain socket
would see each one individually.



More information about the discuss mailing list