hmm, on the jvm implementation i personnaly think it is a good implementation but the unbounded linkedblockingqueue case is not the one for which the impl was designed IMO that's why it sounds strange i think.
about the conf i prefer to not switch to synchrous queue too easily since it can blocks too much (could be a pity for sthg asynchronous ;)). finally between array or linked case the main difference will be the array case is less tolerant but i agree in an application well configured it shouldn't make any difference. *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/21 Bjorn Danielsson <bjorn-apa...@lists.cuspycode.com> > In my opinion this is a bit overkill, at least the options for > using DelayQueue and PriorityBlockingQueue. They require the > Runnable queue elements to implement the Delayed and Comparable > interfaces, respectively. I don't see how to make use of that in > an EJB method call. > > I looked at the Sun ThreadPoolExecutor docs and have now played > a little with it in a standalone program. I honestly think the > design is a bit bizarre. I would expect the thread pool to expand > to max capacity before tasks are put in the wait queue. For the > purpose of optimizing CPU core utilization, the number of threads > in the operating system run-queue is the only important number, > not the number of provisioned threads in a JVM thread pool. > But this is slightly off-topic here. > > I believe it's enough to have just one more configuration > property for TomEE: AsynchronousPool.QueueSize. If this is 0, > let the container use a SynchronousQueue. Otherwise use a > LinkedBlockingQueue with the specified capacity. That way it's > possible to have any of the three queueing strategies mentioned > in the ThreadPoolExecutor javadocs. I can't imagine a situation > where using an ArrayBlockingQueue instead of a bounded > LinkedBlockingQueue in TomEE really makes a big difference, > but I could be wrong about that. > > -- > Björn Danielsson > Cuspy Code AB > > > David Blevins <david.blev...@gmail.com> wrote: > > On Aug 20, 2012, at 10:55 AM, Romain Manni-Bucau wrote: > > > >> that's because we use a linked blocking queue > >> > >> maybe we should make it configurable, not sure... > > > > > > Made it configurable. Code is basically: > > > > public static AsynchronousPool create(AppContext appContext) { > > final Options options = appContext.getOptions(); > > > > final String id = appContext.getId(); > > final int corePoolSize = > options.get("AsynchronousPool.CorePoolSize", 10); > > final int maximumPoolSize = > Math.max(options.get("AsynchronousPool.MaximumPoolSize", 20), corePoolSize); > > final Duration keepAliveTime = > options.get("AsynchronousPool.KeepAliveTime", new Duration(60, > TimeUnit.SECONDS)); > > final BlockingQueue queue = > options.get("AsynchronousPool.QueueType", QueueType.LINKED).create(options); > > > > return new AsynchronousPool(id, corePoolSize, maximumPoolSize, > keepAliveTime, queue); > > } > > > > private static enum QueueType { > > ARRAY, > > DELAY, > > LINKED, > > PRIORITY, > > SYNCHRONOUS; > > > > public BlockingQueue create(Options options) { > > switch (this) { > > case ARRAY: { > > return new > ArrayBlockingQueue(options.get("AsynchronousPool.QueueSize", 100)); > > } > > case DELAY: { > > return new DelayQueue(); > > } > > case LINKED: { > > return new > LinkedBlockingQueue(options.get("AsynchronousPool.QueueSize", > Integer.MAX_VALUE)); > > } > > case PRIORITY: { > > return new PriorityBlockingQueue(); > > } > > case SYNCHRONOUS: { > > return new > SynchronousQueue(options.get("AsynchronousPool.QueueFair", false)); > > } > > default: { > > // The Options class will throw an error if the user > supplies an unknown enum string > > // The only way we can reach this is if we add a new > QueueType element and forget to > > // implement it in the above switch statement. > > throw new IllegalArgumentException("Unknown > QueueType type: " + this); > > } > > } > > } > > } >
