| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
Re: [Xen-API] Xen Management API draft
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
|
|
|
| |
|
Home