You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Johnny Macnum <jo...@hotmail.com> on 2014/02/10 18:45:12 UTC
Usage of ThreadPoolExecutor in TomEE
Hello,
I'm using the framework Activiti for dealing with BPM projects.
In Activiti, a job executor exists to handle asynchronous tasks.
It manages this via ThreadPoolExecutor.
I'm wondering what kinds of issues can happen if I try to use this feature in TomEE.
Does anybody have already tried to handle thread pool in TomEE ?
Regards
Jonathan
-------
Job executor from Activiti
public class DefaultJobExecutor extends JobExecutor {
private static Logger log = LoggerFactory.getLogger(DefaultJobExecutor.class);
protected int queueSize = 3;
protected int corePoolSize = 3;
private int maxPoolSize = 10;
protected BlockingQueue<Runnable> threadPoolQueue;
protected ThreadPoolExecutor threadPoolExecutor;
protected void startExecutingJobs() {
if (threadPoolQueue==null) {
threadPoolQueue = new ArrayBlockingQueue<Runnable>(queueSize);
}
if (threadPoolExecutor==null) {
threadPoolExecutor = new ThreadPoolExecutor(corePoolSize, maxPoolSize, 0L, TimeUnit.MILLISECONDS, threadPoolQueue);
threadPoolExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
}
startJobAcquisitionThread();
}
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
That's the common workaround, keep in mind you are in the EJB context
then (rarely an issue) so some thing can not work as in the webapp
(jndi, security for instance)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-11 15:25 GMT+01:00 Laird Nelson <lj...@gmail.com>:
> On Mon, Feb 10, 2014 at 9:36 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> EE spec mention things work while in EE context. If Activiti uses it own
>> thread pool you are no more in this context.
>
>
> Yes; that was my point exactly. It looks like the class that the original
> author posted can be replaced in some way, and I was saying that if it
> could be replaced with an instance of my ExecutorService-implementing
> singleton bean<http://lairdnelson.wordpress.com/2012/08/19/java-ee-compatible-abstractexecutorservice-im-6803/>,
> then the thread pool would be run and managed by TomEE. Thanks for the
> response.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Laird Nelson <lj...@gmail.com>.
On Mon, Feb 10, 2014 at 9:36 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> EE spec mention things work while in EE context. If Activiti uses it own
> thread pool you are no more in this context.
Yes; that was my point exactly. It looks like the class that the original
author posted can be replaced in some way, and I was saying that if it
could be replaced with an instance of my ExecutorService-implementing
singleton bean<http://lairdnelson.wordpress.com/2012/08/19/java-ee-compatible-abstractexecutorservice-im-6803/>,
then the thread pool would be run and managed by TomEE. Thanks for the
response.
Best,
Laird
--
http://about.me/lairdnelson
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
EE spec mention things work while in EE context. If Activiti uses it own
thread pool you are no more in this context. EE 7 proposes concurrency
utilities to solve half of it but not cdi scope issue when they need to be
thread related (request, session, ... scopes)
Le 11 févr. 2014 01:13, "Laird Nelson" <lj...@gmail.com> a écrit :
> On Mon, Feb 10, 2014 at 10:20 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > object relying on EE stuff (@RequestScoped, EJB...) will be broken. No
> > guarantee it would work.
> >
>
> I've been puzzling over this comment all day. Did I miss something? I
> thought TomEE was Java EE Web Profile certified? I surely must have missed
> something; my apologies if so.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Laird Nelson <lj...@gmail.com>.
On Mon, Feb 10, 2014 at 10:20 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> object relying on EE stuff (@RequestScoped, EJB...) will be broken. No
> guarantee it would work.
>
I've been puzzling over this comment all day. Did I miss something? I
thought TomEE was Java EE Web Profile certified? I surely must have missed
something; my apologies if so.
Best,
Laird
--
http://about.me/lairdnelson
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Jonathan,
object relying on EE stuff (@RequestScoped, EJB...) will be broken. No
guarantee it would work.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-10 19:18 GMT+01:00 Laird Nelson <lj...@gmail.com>:
> On Mon, Feb 10, 2014 at 9:45 AM, Johnny Macnum <jo...@hotmail.com>wrote:
>
>> I'm wondering what kinds of issues can happen if I try to use this feature
>> in TomEE.
>>
>
> Hi; you may not care, but technically speaking invoking threads that aren't
> under the management of the container is a violation of the Java EE
> specification. (Most containers don't care; TomEE may indeed be one of
> those; and you may not care whether you're in compliance or not.)
>
> I see that the method you've excerpted is protected (so you could
> conceivably override it). (It also looks like DefaultJobExecutor could be
> replaced.) If you do choose to override it, you could use the approach I
> detail here:
> http://lairdnelson.wordpress.com/2012/08/19/java-ee-compatible-abstractexecutorservice-im-6803/
> That is a Java-EE-compliant way to offload thread management to the
> container's thread pools that handle asynchronous EJB invocation.
>
> Anyway, I hope this helps.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
Re: Usage of ThreadPoolExecutor in TomEE
Posted by Laird Nelson <lj...@gmail.com>.
On Mon, Feb 10, 2014 at 9:45 AM, Johnny Macnum <jo...@hotmail.com>wrote:
> I'm wondering what kinds of issues can happen if I try to use this feature
> in TomEE.
>
Hi; you may not care, but technically speaking invoking threads that aren't
under the management of the container is a violation of the Java EE
specification. (Most containers don't care; TomEE may indeed be one of
those; and you may not care whether you're in compliance or not.)
I see that the method you've excerpted is protected (so you could
conceivably override it). (It also looks like DefaultJobExecutor could be
replaced.) If you do choose to override it, you could use the approach I
detail here:
http://lairdnelson.wordpress.com/2012/08/19/java-ee-compatible-abstractexecutorservice-im-6803/
That is a Java-EE-compliant way to offload thread management to the
container's thread pools that handle asynchronous EJB invocation.
Anyway, I hope this helps.
Best,
Laird
--
http://about.me/lairdnelson