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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/