Community
Participate
Working Groups
Build Identifier: 7.3.0.v20110203 ExecutorThreadPool never grows above corePoolSize. It's supposed to grow up to maximumPoolSize, right? It does not. When created with core size 8 and maximum size 100 - it process at most 6 requests at a time. It does not grow. (the other two threads are taken by acceptor or selector) The workaround is simple - just set corePoolSize is to maximumPoolSize. But it's rather unfortunate to notice it in production :-) Verified on: * linux - ubuntu lucid * sun jvm 6_u22, 6_u24 * jetty 7.3.0.v20110203, 7.2.2.v20101205 and 7.1.6.v20100715 Reproducible: Always Steps to Reproduce: // pool ThreadPool pool = new ExecutorThreadPool(3, 100, 60, TimeUnit.SECONDS); // selector SelectChannelConnector connector = new SelectChannelConnector(); connector.setThreadPool(pool); // server Server server = new Server(); server.addConnector(connector); // try to send two requests in parallel
Simone, Can you take a look at this one as your such a big fan of the JVM thread pool :-) Jan, the Jetty Queued Thread pool has been demonstrated to have a lot better performance than the executor. cheers
The behavior reported is expected and it's documented in java.util.concurrent.ThreadPoolExecutor (http://download.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html), specifically in the section "Queuing". While I admit it may be counter-intuitive, that's the JDK behavior, it is documented, and Jetty's ExecutorThreadPool just wraps JDK's ThreadPoolExecutor, so it inherits the behavior. Specifically, from the Javadocs linked above: "Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to wait in the queue when all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.)"
You're right! I'm going to read the javadocs better next time ;-) Thanks, Jan
