This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Mon, 26 Jun 2006 13:44:46 -0500
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jun 2006 11:44:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060626155433.GD10089@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <20060625154903.GC30399@xxxxxxxxxx> <20060626155433.GD10089@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060615)
Ewan Mellor wrote:
On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:

The same issue is true of the proposed mechanism for asynchronous invocation
invocation of APIs - it also requires the client to make requests polling
for completion of the API which is not really buying any performance benefit.
Unless the client actually wanted the 'estimated time of completion' data,
they might as well just send a regular synchronous request & use select()
or poll() system calls on the HTTP socket to do a non-blocking wait for completion client side.

Here's a thought -- how about we provide a call with the semantics of "please
give me the next event", which blocks at the server until an event becomes
available.  The client would call the server with registration for events, and
then make this synchronous call in another thread or in a select() loop, which
would block until an event arrives.  If the connection gets broken without an
event, just reconnect and block again.

Would this work?

I've got code that does this (for a different project). As long as your XML-RPC server is threaded, you can block the call however long you want. It's a little tricky not leaking threads when you block (if you block merely on a condition, if the client closes the connection you'll potentially block indefinitely).

I've been told that proxies are a real PITA with these sort of tricks though. Many enforce very support keep-alive timeouts. Certainly is better than nothing though.


Anthony Liguori


xen-api mailing list

xen-api mailing list