Open Stack

Jim,

I'm redirecting your question to oslo folks, as I'm afraid my answer can 
be wrong.

On 07/23/2015 01:55 PM, Jim Rollenhagen wrote:
> 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?

I believe answer is no, and the reason IIUC is that Futurist executors 
are modeled after stdlib executors, but I may be wrong.

>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>