On Fri, Jul 15, 2011 at 16:18:54 +0100, Daniel P. Berrange wrote: > On Fri, Jul 15, 2011 at 04:41:38PM +0200, Jiri Denemark wrote: > > When an asynchronous job is running while another API that is > > incompatible with that job is called, we now try to wait until the job > > finishes and either run the API or fail with timeout. I guess nicer > > solution is to just fail such API immediately and let the application > > retry once the asynchronous job ends. > > I'm not entirely convinced this is a good idea, because IIUC, what this > is in effect doing is having a zero second timeout. Previously we would > wait forever, currently we wait upto 30 seconds IIRC, and now we'll > wait 0 seconds. I think this will create lots of spurious timeouts > for applications to needlessly deal with. I'm not sure how far in the past are you referring to by saying "previously". Anyway since few years age we've been waiting up to 30 seconds. Now we would wait for 0 seconds but only in case current job is migration/save/dump. If the job doesn't finish in 30 seconds, we would just fail with timeout providing quite unhelpful error message. This way we would provide a better error message. Removing the timeout should be fine in this case since in most cases (migration/save) the domain won't exist after the job finishes anyway so the current API would fail anyway. However, if we still want to have the timeout there, we could just make the error message better in case we're waiting for incompatible async job to finish. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list