Re: [Xen-API] Xen Management API draft

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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.
Regards,

Anthony Liguori

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

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