On Tue, Sep 13, 2016 at 06:58:42PM +0000, Alin Serdean wrote: > > -----Original Message----- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Friday, August 26, 2016 6:54 PM > > To: Alin Serdean <aserd...@cloudbasesolutions.com> > > Cc: dev@openvswitch.org > > Subject: Re: [ovs-dev] [PATCH] Windows: Allow online compacting > > > > On Fri, Aug 12, 2016 at 07:39:32AM +0000, Alin Serdean wrote: > > > This patch allows online compacting to be done under Windows. > > > > > > To achieve the above we need to close all file handles before trying > > > to rename the file, switch from rename to MoveFileEx (because > > > rename/MoveFile fails if the destination exists), reopen the right > > > type of log after the rename. > > > > > > Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com> > > > > I think that this introduces a new kind of failure. On other OSes, > > ovsdb_file_compact() always leaves 'file' open and usable regardless of > > whether it succeeds or fails. I think that on Windows it can fail and > > close 'file'. > > The callers don't expect that, so there needs to be some way to it to report > > the problem. And then we have to figure out how the database server > > should deal with it if its database got closed and cannot be reopened. > [Alin Serdean] Thanks for the review! You are right Ben, it introduces a new > problem. > I am unware if the requests can be pended until we can reopen the database. > If the requests can be pended we could add a retry counter otherwise > we could log the error and exit out for the time being if something 'happens' > between close and open (since it has a slim chance of producing) and let the > service manager deal with a database service restart.
It's a difficult choice. I think that I lean toward making the service fail and exit with an error (VLOG_FATAL, perhaps). Otherwise, we would have to introduce a new mode where ovsdb-server periodically tries to reopen its database and either rejects transaction requests entirely or goes read-only. *Maybe* that is the right approach, but it would require careful testing. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
