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 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
