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 10:39:41 GMT
yeah it works as expected but it is not what we (often) want, typically
RejectedExecutionException are an issue

in fact that's the only difference between all cases: when
will RejectedExecutionException be thrown

the linked case is the one avoiding it the more (but using more memory)..

solution are always a compromise ;)

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*




2012/8/21 Bjorn Danielsson <bjorn-apache@lists.cuspycode.com>

> Can you give an example when a SynchronousQueue would block
> too much? In my tests it works exactly like I would expect a
> bounded queue with a size of zero to behave. The thread pool
> reaches MaximumPoolSize and then a RejectedExecutionException
> is thrown. For a LinkedBlockingQueue with size 1, exactly the
> same thing happens but one submission later, since one element
> was queued before the thread pool started to expand.
>
> For the array vs bounded linked queue, I can't see how there
> are any practical differences for a ThreadPoolExecutor except
> for how memory is used to store the Runnable pointers in the
> queue.
>
> --
> Björn Danielsson
> Cuspy Code AB
>
>
> Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
> > 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