<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 July 2015 at 08:40, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all!<br>
<br>
Currently _spawn_worker in the conductor manager raises NoFreeConductorWorker if pool is already full. That's not very user friendly (potential source of retries in client) and does not map well on common async worker patterns.<br>
<br>
My understanding is that it was done to prevent the conductor thread from waiting on pool to become free. If this is true, we no longer need it after switch to Futurist, as Futurist maintains internal queue for its green executor, just like thread and process executors in stdlib do. Instead of blocking the conductor the request will be queued, and a user won't have to retry vague (and rare!) HTTP 503 error.<br>
<br>
WDYT about me dropping this exception with move to Futurist?<br></blockquote><div><br></div><div>For a bit more context, Dmitry has a spec to move to Futurist[1]. My understanding is that Futurist will enqueue tasks if the worker pool is full. So if we move to Futurist, we will have to drop the exception/change the existing behaviour, unless we want Futurist to provide something so we can continue with our existing behaviour.</div><div><br></div><div>I am fine with changing the behaviour so that tasks are enqueued and we don't raise that NoFreeConductorWorker exception. That seems to make sense to me. But I'm not an operator.</div><div><br></div><div>--ruby</div><div><br></div><div>[1] <a href="http://specs.openstack.org/openstack/ironic-specs/specs/liberty/futurist.html">http://specs.openstack.org/openstack/ironic-specs/specs/liberty/futurist.html</a></div></div></div></div>