Thread limit in ImageFactory?

Justin Clift jclift at redhat.com
Thu Jul 12 21:26:04 UTC 2012


On 13/07/2012, at 3:16 AM, Steve Loranz wrote:
> Since pure python doesn't have the ability to forcibly terminate a thread, paste does some juggling of a pool of threads that grows and contracts as needed in an attempt to both conserve memory and stay responsive. I'm not 100% certain what the thinking is in limiting the number of requests a responsive thread can process in its lifetime, but it's a configurable limit (100 being the paste default) and we can play around with the settings some to maybe optimize this a bit. It probably makes sense to try and make some more of this configurable... Things like the size of the thread pool, the number of available threads in the pool, and the number of requests a thread can process in its life.

Thanks Steve. Good info. :)

Making these pieces configurable sounds like a decent idea (at some point).

It only seems to happen when launching many instances at the same time (10 for me), so it's probably not something many people would hit in the real world at this point.

> I'm not sure why Conductor is reporting "instance vanished". A new thread is created for the one that expires and imagefactory should still be available. There may be some lag happening in the thread creation, which adjusting the above settings would alleviate.

Thinking through the stuff you mention above, it sounds like two completely separate problems, that probably just show up in the same scenario. :)

Regards and best wishes,

Justin Clift

--
Aeolus Community Manager
http://www.aeolusproject.org




More information about the aeolus-devel mailing list