[ovs-dev] [dev master 2/3] bridge: Make ovs-vswitchd run again if status_txn commit fails.

Alex Wang alexw at nicira.com
Mon Jun 9 22:05:20 UTC 2014


On Mon, Jun 9, 2014 at 2:36 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Sun, Jun 01, 2014 at 10:04:29PM -0700, Alex Wang wrote:
> > This commit adds logic that checks the return value of status_txn
> > transaction and runs the update again if the transaction fails.
> >
> > Signed-off-by: Alex Wang <alexw at nicira.com>
>
> I am not sure that you understand what TXN_INCOMPLETE means.  It means
> that a transaction has been queued up to send to the database server,
> but the database server has not yet replied.  Some of the comments in
> this commit imply that we should retry the transaction in the case of
> TXN_INCOMPLETE, but no, that's not the case; we should just wait for
> the database server to respond.
>
> It seems to me that status_txn_try_again is only used after the
> transaction finishes, since if status == TXN_INCOMPLETE then we're
> still waiting for it to complete and status_txn is still nonnull.  So
> I would update this comment to remove the mention of "incomplete":
>



Thanks for correcting my understanding.  I forgot to follow the
instant_stats_wait() logic when removing it.  I'll adjust the code
accordingly.





> > + * If the previous database transaction was incomplete or failed (is not
> > + * 'TXN_SUCCESS' or 'TXN_UNCHANGED'), 'status_txn_try_again' is set to
> true,
> > + * which will cause the main thread wake up soon and retry the status
> update.
> >   */
> >  static struct ovsdb_idl_txn *status_txn;
> > +static bool status_txn_try_again;
>
> Also, here we really only care to set status_txn_try_again if the
> transaction is somehow complete, right?  Then I would move the new
> code inside the previous "if" block that only runs if status !=
> TXN_INCOMPLETE.  Also, TXN_UNCOMMITTED should be impossible here,
> since we called ovsdb_idl_txn_commit() a few lines earlier.
>


I'll do that.




> > @@ -2453,6 +2458,14 @@ bridge_run(void)
> >              ovsdb_idl_txn_destroy(status_txn);
> >              status_txn = NULL;
> >          }
> > +
> > +        /* Sets the 'status_txn_try_again' if the transaction fails or
> > +         * is still incomplete. */
> > +        if (status == TXN_SUCCESS || status == TXN_UNCOMMITTED) {
> > +            status_txn_try_again = false;
> > +        } else {
> > +            status_txn_try_again = true;
> > +        }
> >      }
> >
> >      run_system_stats();
>
> There seems to be some similar confusion here.  If the transaction is
> incomplete, then we shouldn't do any kind of timer-based waiting, we
> should instead wait for the transaction to complete:
>


I'll fix it.


> > @@ -2486,11 +2499,11 @@ bridge_wait(void)
> >          poll_timer_wait_until(stats_timer);
> >      }
> >
> > -    /* If the status database transaction is 'TXN_INCOMPLETE' in this
> run,
> > -     * register a timeout in 'STATUS_CHECK_AGAIN_MSEC'.  Else, wait on
> the
> > -     * global connectivity sequence number.  Note, this also helps batch
> > -     * multiple status changes into one transaction. */
> > -    if (status_txn) {
> > +    /* If the status update to database needs to be run again
> (transaction
> > +     * fails or incomplete), registers a timeout in
> 'STATUS_CHECK_AGAIN_MSEC'.
> > +     * Else, waits on the global connectivity sequence number.  Note,
> this also
> > +     * helps batch multiple status changes into one transaction. */
> > +    if (status_txn_try_again) {
> >          poll_timer_wait_until(time_msec() + STATUS_CHECK_AGAIN_MSEC);
> >      } else {
> >          seq_wait(connectivity_seq_get(), connectivity_seqno);
> > --
> > 1.7.9.5
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140609/75ef9cc8/attachment-0005.html>


More information about the dev mailing list