It's probably a long-standing bug then.
Does the problem seem correlated with a high transaction rate on the
database server, or does it happen even at a low to medium pace? Do you
have other hints to what might trigger the issue?
On Wed, Jun 10, 2015 at 06:19:19PM -0700, Saurabh Shrivastava (सौ
This happens with an older (more than 6 month) OVSDB server. It is
difficult to reproduce this behaviour.
--
Saurabh (सौरभ)
On Wed, Jun 10, 2015 at 6:06 PM, Ben Pfaff wrote:
> The database server should always report a single transaction as a
> single update. It can sometimes merge multiple tr
The database server should always report a single transaction as a
single update. It can sometimes merge multiple transactions into one
update but it's a bug if it ever splits a single transaction into
multiple updates.
Is this with bleeding-edge OVS from master, by any chance? We've had a
lot o
The transaction reply appears after all the updates are received (but I
dont have those traces at this time)
Here is the good case where all the changes to the database come in one
giant update instead of split up into 3 updates. Note that in the bad case
the 3 row deletes appeared as 3 different
If the deletes are within a single transaction, they'll be reported as
part of a single update, and the IDL will present them all together as a
unit.
If the deletes happen in different transactions then they'll be reported
sequentially, in the same order they were applied to the database.
If you'
The updates you're showing me might not be related to the transaction at
all, since the update doesn't mention the Mcast_Macs_Remote table.
Where's the transaction reply?
On Wed, Jun 10, 2015 at 09:50:47AM -0700, Saurabh Shrivastava (सौरभ श्रीवास्तव)
wrote:
> An example of where deletes are recei
An example of where deletes are received out of order: Mcast_Macs_Remote
points to Physical_Locator_Set which points to Physical_Locator. When a
transaction deletes Mcast_Macs_Remote, delete for Physical_Locator_Set is
received first.
[027 m 05/26/15 22:22:16.824] A:dc_rpc:OVS: ovs|09826|jsonrpc|
Thanks Ben. I have seen that when a transaction is deleting rowA which
points to rowB which points to rowC, and if all the references to rowB and
rowC are gone, the updates generated can be in any order ie rowC delete can
be received before deletes for rowA or rowB. Should this be expected for
"del
On Wed, Jun 10, 2015 at 07:55:20AM -0700, Ben Pfaff wrote:
> On Tue, Jun 09, 2015 at 11:16:34PM -0700, Saurabh Shrivastava (सौरभ
> श्रीवास्तव) wrote:
> > When OVSDB server sends updates to an OVSDB client, the IDL changes
> > idl_seqno. When idl_seqno changes, the client can rebrowse the IDL and l
On Tue, Jun 09, 2015 at 11:16:34PM -0700, Saurabh Shrivastava (सौरभ श्रीवास्तव)
wrote:
> When OVSDB server sends updates to an OVSDB client, the IDL changes
> idl_seqno. When idl_seqno changes, the client can rebrowse the IDL and look
> for changes.
>
> Does OVSDB server guarantee that the update
Hi,
When OVSDB server sends updates to an OVSDB client, the IDL changes
idl_seqno. When idl_seqno changes, the client can rebrowse the IDL and look
for changes.
Does OVSDB server guarantee that the updates always maintain referential
integrity for row creation and row updates i.e. if the client b
11 matches
Mail list logo
