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