Open Stack

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