openejb-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Number of simultaneous @Asynchronous threads
Date Tue, 21 Aug 2012 09:39:37 GMT
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-apache@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.blevins@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);
> >                 }
> >             }
> >         }
> >     }
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message