On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote: > 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? >
I kind of like this, but with my operator hat on this is a bit scary. Does Futurist just queue all requests indefinitely? Is it configurable? Am I able to get any insight into the current state of that queue? Just indefinitely queueing up everything seems like it could end with a system that's backlogged to death, with no way to determine if that's actually the problem or not. // jim __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev