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|DBG|ssl:
135.227.147.205:43858: send request, method="transact",
params=["hardware_vtep",{"
lock":"my_controller","op":"assert"},{"table":"Mcast_Macs_Remote","where":[["_uuid","==",["uuid","63bdbbfe-0f90-4f33-acdd-f6334852302c"]]],"op":"delete"},{"comment":"thdl
20","op":"comment"}], id=201
[027 m 05/26/15 22:22:16.832] A:dc_rpc:OVS: ovs|09828|poll_loop|DBG|wakeup
due to [POLLIN] on fd 154 (FIFO) at
/home/saurabh/dc35/os/ovs/lib/stream-fd.c:131 (0% CPU usage)
[027 m 05/26/15 22:22:16.835] A:dc_rpc:OVS: ovs|09829|poll_loop|DBG|wakeup
due to [POLLIN] on fd 246 (135.227.144.122:6632<->135.227.147.205:43858) at
/home/saurabh/dc35/os/ovs/lib/stream-ssl.c:744 (0% CPU usage)
[027 m 05/26/15 22:22:16.838] A:dc_rpc:OVS: ovs|09830|jsonrpc|DBG|ssl:
135.227.147.205:43858: received notification, method="update",
params=[null,{"Physical_Locator_Set":{"ff6908de-98aa-4c30-8809-7e1395ea13c9":{"old":{"locators":["uuid","901cdefe-0292-48bb-a9df-6a4837061931"]}}}}]
[027 m 05/26/15 22:22:16.846] A:dc_rpc:OVS: ovs|09831|jsonrpc|DBG|ssl:
135.227.147.205:43858: received notification, method="update",
params=[null,{"Physical_Locator":{"901cdefe-0292-48bb-a9df-6a4837061931":{"old":{"dst_ip":"10.50.50.1","encapsulation_type":"vxlan_over_ipv4"}}}}]
--
Saurabh (सौरभ)
On Wed, Jun 10, 2015 at 9:41 AM, Saurabh Shrivastava (सौरभ श्रीवास्तव) <
[email protected]> wrote:
> 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
> "deletes"?
>
>
> --
> Saurabh (सौरभ)
>
> On Wed, Jun 10, 2015 at 8:15 AM, Ben Pfaff <[email protected]> wrote:
>
>> 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 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 browses
>> the
>> > > IDL it should never run into a situation where rowA in tableA points
>> to a
>> > > non-existent rowB in tableB because the update for rowA has arrived
>> but
>> > > update for rowB is still in flight.
>> >
>> > Yes.
>>
>> I sent out a patch to document this:
>> http://openvswitch.org/pipermail/dev/2015-June/056200.html
>>
>
>
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
