Mailing-List: contact users-help@openejb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openejb.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Bjorn Danielsson <bjorn-apache@lists.cuspycode.com>
To: users@openejb.apache.org
Subject: Re: Number of simultaneous @Asynchronous threads
Organization: Cuspy Code AB
References: <yqfr4r4jn7k.fsf@kali.pri>
	<CAPBQWzK1URugd3QGKJrr3tc_=CxZsd7Ta4Urz2VKF6X-bG4uBg@mail.gmail.com>
	<CACLE=7P4tmP1pQWFu6km0ViKx_NUrCKQrpioM8KrQJiAv2MGTA@mail.gmail.com>
	<1345419028949-4656908.post@n4.nabble.com>
	<CACLE=7OWk7i_+RWAkiBmO4mOLJM7z4N6nnNxi-r13re74MPrZw@mail.gmail.com>
	<yqf7gstk5se.fsf@kali.pri>
	<CACLE=7NJySP98FgnHy9vWXPyTU8KrziJ_YeF=2O+bH+X+0oRog@mail.gmail.com>
	<yqfmx1pilb4.fsf@kali.pri>
	<B1739177-4A5C-4618-B1A7-6275D4DD6186@gmail.com>
	<CACLE=7M5O+7G5WF4pMh=GLfimWwuG4sHx+znnsE9EawnjKkbQw@mail.gmail.com>
	<DB3E5353-8D75-4AC2-8AF7-7F5A4962EF61@gmail.com>
Date: Tue, 21 Aug 2012 11:18:35 +0200
In-Reply-To: <DB3E5353-8D75-4AC2-8AF7-7F5A4962EF61@gmail.com> (David Blevins's
	message of "Mon, 20 Aug 2012 12:33:51 -0700")
Message-ID: <yqfsjbghac4.fsf@kali.pri>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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.

--=20
Bj=C3=B6rn 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
>>=20
>> maybe we should make it configurable, not sure...
>
>
> Made it configurable.  Code is basically:
>
>     public static AsynchronousPool create(AppContext appContext) {
>         final Options options =3D appContext.getOptions();
>
>         final String id =3D appContext.getId();
>         final int corePoolSize =3D options.get("AsynchronousPool.CorePool=
Size", 10);
>         final int maximumPoolSize =3D Math.max(options.get("AsynchronousP=
ool.MaximumPoolSize", 20), corePoolSize);
>         final Duration keepAliveTime =3D options.get("AsynchronousPool.Ke=
epAliveTime", new Duration(60, TimeUnit.SECONDS));
>         final BlockingQueue queue =3D options.get("AsynchronousPool.Queue=
Type", QueueType.LINKED).create(options);
>
>         return new AsynchronousPool(id, corePoolSize, maximumPoolSize, ke=
epAliveTime, queue);
>     }
>
>     private static enum QueueType {
>         ARRAY,
>         DELAY,
>         LINKED,
>         PRIORITY,
>         SYNCHRONOUS;
>
>         public BlockingQueue create(Options options) {
>             switch (this) {
>                 case ARRAY: {
>                     return new ArrayBlockingQueue(options.get("Asynchrono=
usPool.QueueSize", 100));
>                 }
>                 case DELAY: {
>                     return new DelayQueue();
>                 }
>                 case LINKED: {
>                     return new LinkedBlockingQueue(options.get("Asynchron=
ousPool.QueueSize", Integer.MAX_VALUE));
>                 }
>                 case PRIORITY: {
>                     return new PriorityBlockingQueue();
>                 }
>                 case SYNCHRONOUS: {
>                     return new SynchronousQueue(options.get("Asynchronous=
Pool.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);
>                 }
>             }
>         }
>     }