Hi all!
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.
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.
WDYT about me dropping this exception with move to Futurist?
Dmitry
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
