On Thu, Jun 10, 2010 at 8:06 AM, Gregg Wonderly <[email protected]> wrote: > As was kind of discussed earlier, TPE uses max threads in a different way > then most people would think.
I think we will end up needing a very precise description of the behavior we expect from our thread manager, esp. regarding queueing. If we can't know beforehand which incoming calls are critical, but have a (natural) upper limit on native threads we can instantiate, then perhaps the manager should be configured to reject the incoming call entirely instead of queueing it. Below the natural maximum amount of native threads, we can force a new thread to be created per call (assuming none are idle). From the TPE documentation, it seems this is covered in the class JavaDocs, under Queueing, "Direct handoffs. A good default choice for a work queue is a SynchronousQueue that hands off tasks to threads without otherwise holding them. Here, an attempt to queue a task will fail if no threads are immediately available to run it, so a new thread will be constructed. This policy avoids lockups when handling sets of requests that might have internal dependencies. Direct handoffs generally require unbounded maximumPoolSizes to avoid rejection of new submitted tasks. This in turn admits the possibility of unbounded thread growth when commands continue to arrive on average faster than they can be processed."[1] Patrick [1] http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
