Re: [Xen-API] Xen Management API draft

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
>
>   
> > Finally, a higher level question - the API is still basically unidirectional,
> > poll based model. By this I mean, if I want to detect changes in a guest VMs
> > lifecycle state (eg, from running -> paused), then I have no choice but to
> > poll the 'power_state' field on every VM i'm interested in. If the app using
> > the API is a GUI app, then this polling is going to have to be done pretty
> > frequently (once per second or more) to provide an acceptable refresh in the 
> > UI. I'm concerned that polling so frequently over an HTTP / XML-RPC protocol
> > is going to impose a very significant performance hit on the host machine.
> > It would be very desriable if there was a formal API for getting asynchronous
> > callbacks notifying the client of changes in a VM's lifecycle state. I know
> > this is not really possible with XML-RPC, but I wanted to bring it up as a
> > use-case none-the-less in case there are alternate ways to provide such a
> > capability. 
> >
> > 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?
>   
Don't think this would scale.  Seems a little nasty with a few hundred 
clients (with open connections / sessions) waiting on events.
Regards,
Jim

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api