[Libvir] Patch to 'ping' XenD when opening connection

Daniel Veillard veillard at redhat.com
Mon Jun 12 23:21:47 UTC 2006


On Mon, Jun 12, 2006 at 10:21:04PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 12, 2006 at 11:50:36AM -0400, Daniel Veillard wrote:
> > On Mon, Jun 12, 2006 at 04:01:33PM +0100, Daniel P. Berrange wrote:
> > > Currently the XenD driver's implementation of the 'open' method will return
> > > success, regardless of whether XenD is even present. The attached patch
> > > makes the open method do a 'ping' to see if XenD is actually there, returning
> > > failure if it is not. This ensures that the XenD driver backend doesn't get
> > > activated when connecting to alternate non-Xen backends, such as the test
> > > backend I committed last week.  
> > 
> >   Yes that makes sense. I think originally the point was to be able to start 
> > some monitoring tool before xend was started (and it's simpler) but now
> > this need fixing, you are right.
> > 
> > > The current 'ping' is simply to call the xenDaemonGetVersion() method since
> > > that's a pretty simle & low-overhead way to testing livliness of XenD. Any
> > > suggestions for a better ping - if not I'll go ahead & commit this change 
> > [...]
> > > +    /* A sort of "ping" to make sure the daemon is actually
> > > +       alive & well, rather than just assuming it is */
> > > +    if ((ret = xenDaemonGetVersion(conn, &version)) < 0) {
> > 
> >    hum, it seems the connection should be closed in that error case, or
> > we may be leaking. Not 100% since I don't have the full context right now.
> > Once checked, yes please commit :-)
> 
> Each method call in the xenDaemon code does a full HTTP connection setup & tear
> down pair, so there are no resources kept open across method calls. Thus there
> is no cleanup neccessary (xenDaemonClose is a no-op already).

  Hum, that may change (c.f. HTTP keep-alive), let's just call the no-op :-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/




More information about the libvir-list mailing list