On Mon, Jun 26, 2006 at 04:54:33PM +0100, 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?
That's an interesting idea, avoiding polling since the client can just watch
the socket in a select() / poll() call. It would obviously require keeping
a 2nd connection open to the hypervisor, however, that's not too onerous so
it's certainly a plausible solution even if it is a bit of a nasty hack.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home
xen.org, 