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