You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Paul Carter-Brown <pa...@smilecoms.com> on 2017/10/10 22:13:11 UTC
DefaultManagedExecutorService lookup in JNDI
Hi,
According to EE7 spec I should be able to do the following:
try {
new
InitialContext().lookup("java:comp/DefaultManagedExecutorService");
} catch (NamingException e) {
log.warn("Error:", e);
}
In TomEE 7.0.4 I get a NamingException:
javax.naming.NameNotFoundException: Name [DefaultManagedExecutorService] is
not bound in this Context. Unable to find [DefaultManagedExecutorService].
at org.apache.naming.NamingContext.lookup(NamingContext.java:816)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at com.test.beanmanagerbug.MyServlet.init(MyServlet.java:36)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1183)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1099)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:989)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4931)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5241)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1419)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Any idea how I can get the DefaultManagedExecutorService in an unmanaged
bean (i.e. using JNDI)
Thanks
Paul
--
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
Re: DefaultManagedExecutorService lookup in JNDI
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Hi Paul,
You might like to consider investigating the @Asynchronous annotation.
It could solve a few of your headaches, without requiring the
ManagedExecutorService.
Here is a simple example - But it can do a lot more:
http://tomee.apache.org/examples-trunk/async-methods/ - It's basically
like a free and managed ManagedExecutorService without the overhead if
you get my drift?
Andy.
On 11/10/17 01:10, Paul Carter-Brown wrote:
> Thanks Romain/Andy,
>
> openejb.environment.default = true fixed it
>
> Does this property merely indicate that the resources should be bound into
> the JNDI tree or does it control whether they are created or not by the
> container?
>
> I found it interesting that this works fine even with that property set to
> false:
>
> @Resource
> private ManagedExecutorService mes;
>
>
> ~~~
>
> In terms of why I need the executor:
>
> The systems we build almost always do a lot in the background in addition
> to servicing incoming requests over HTTP and other protocols. Background
> threads are needed to do things like service discovery, service monitoring,
> rating, event processing, polling external systems etc etc. I bootstrap
> this "background" functionality via a servlet with loadOnStartup and an
> init function that would kick everything off. I was experimenting with
> moving all this background code to be loaded and managed by CDI. As the
> initial servlet init function is within a managed context I could inject
> from there on into the code base to boot everything up. I was thinking of
> using @Singleton/@ApplicationScope managed beans as a way of neatly
> starting these background objects with @PostConstruct once and only once so
> they could do their thing with executors in the background. My recent
> issues with controlling @Singleton/@ApplicationScope objects in
> circumstances with multiple skinny wars in a EAR lead me to rethink using
> CDI and rather use good old Singletons where I can fully control the
> lifecycle of the instance and be sure its background processing is only
> started once. Instead of creating my own threads I'd prefer to use
> ManagedExecutorService and ManagedScheduledExecutorService. It was easy to
> get these when I could inject them but now with singletons and classes that
> are being created outside of the managed context (i.e. with
> Foo.getInstance() as opposed to @Inject Foo) I need to get them from JNDI
> and this is where I hit this particular issue.
>
> Paul
>
>
>
> On 11 October 2017 at 01:46, agumbrecht <ag...@tomitribe.com> wrote:
>
>> Properties are somewhat documented here:
>> http://tomee.apache.org/admin/configuration/server.html - It's not totally
>> obvious in your case that the property named here does what Romain
>> describes, but please feel free to create a ticket on the jira here:
>> https://issues.apache.org/jira/browse/TOMEE if you would like a better
>> description.
>>
>> The managed executor is a way to start threads that the server will attempt
>> to stop on a shutdown. The app server is already multithreaded, so there
>> might be a better way to do what you are intending?
>>
>> Andy.
>>
>>
>>
>> -----
>> --
>> Andy Gumbrecht
>>
>> http://www.tomitribe.com
>> agumbrecht@tomitribe.com
>> https://twitter.com/AndyGeeDe
>>
>> TomEE treibt Tomitribe ! | http://tomee.apache.org
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-
>> f979441.html
>>
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io
Re: DefaultManagedExecutorService lookup in JNDI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
It defines the link only, which means it does the same as your
@Resource. Difference is that if you don't have any @Resource then it
would still do it if true by default. Then if there is a link and no
matching resource then openejb creates one implicitly. This means that
false is a good default avoiding to create not needed resources :).
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
2017-10-11 10:10 GMT+02:00 Paul Carter-Brown <pa...@smilecoms.com>:
> Thanks Romain/Andy,
>
> openejb.environment.default = true fixed it
>
> Does this property merely indicate that the resources should be bound into
> the JNDI tree or does it control whether they are created or not by the
> container?
>
> I found it interesting that this works fine even with that property set to
> false:
>
> @Resource
> private ManagedExecutorService mes;
>
>
> ~~~
>
> In terms of why I need the executor:
>
> The systems we build almost always do a lot in the background in addition
> to servicing incoming requests over HTTP and other protocols. Background
> threads are needed to do things like service discovery, service monitoring,
> rating, event processing, polling external systems etc etc. I bootstrap
> this "background" functionality via a servlet with loadOnStartup and an
> init function that would kick everything off. I was experimenting with
> moving all this background code to be loaded and managed by CDI. As the
> initial servlet init function is within a managed context I could inject
> from there on into the code base to boot everything up. I was thinking of
> using @Singleton/@ApplicationScope managed beans as a way of neatly
> starting these background objects with @PostConstruct once and only once so
> they could do their thing with executors in the background. My recent
> issues with controlling @Singleton/@ApplicationScope objects in
> circumstances with multiple skinny wars in a EAR lead me to rethink using
> CDI and rather use good old Singletons where I can fully control the
> lifecycle of the instance and be sure its background processing is only
> started once. Instead of creating my own threads I'd prefer to use
> ManagedExecutorService and ManagedScheduledExecutorService. It was easy to
> get these when I could inject them but now with singletons and classes that
> are being created outside of the managed context (i.e. with
> Foo.getInstance() as opposed to @Inject Foo) I need to get them from JNDI
> and this is where I hit this particular issue.
>
> Paul
>
>
>
> On 11 October 2017 at 01:46, agumbrecht <ag...@tomitribe.com> wrote:
>
>> Properties are somewhat documented here:
>> http://tomee.apache.org/admin/configuration/server.html - It's not totally
>> obvious in your case that the property named here does what Romain
>> describes, but please feel free to create a ticket on the jira here:
>> https://issues.apache.org/jira/browse/TOMEE if you would like a better
>> description.
>>
>> The managed executor is a way to start threads that the server will attempt
>> to stop on a shutdown. The app server is already multithreaded, so there
>> might be a better way to do what you are intending?
>>
>> Andy.
>>
>>
>>
>> -----
>> --
>> Andy Gumbrecht
>>
>> http://www.tomitribe.com
>> agumbrecht@tomitribe.com
>> https://twitter.com/AndyGeeDe
>>
>> TomEE treibt Tomitribe ! | http://tomee.apache.org
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-
>> f979441.html
>>
>
>
>
> --
>
> *Paul Carter-Brown*
>
> *Group Chief Information Officer*
>
> *Smile Communications Pty (Ltd) *
> Smile +234 (0) 702 000 1234
> Mobile +27 (0) 83 4427 179
> Skype PaulC-B
> paul.carter-brown@smilecoms.com
> www.smilecoms.com
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
>
Re: DefaultManagedExecutorService lookup in JNDI
Posted by Paul Carter-Brown <pa...@smilecoms.com>.
Thanks Romain/Andy,
openejb.environment.default = true fixed it
Does this property merely indicate that the resources should be bound into
the JNDI tree or does it control whether they are created or not by the
container?
I found it interesting that this works fine even with that property set to
false:
@Resource
private ManagedExecutorService mes;
~~~
In terms of why I need the executor:
The systems we build almost always do a lot in the background in addition
to servicing incoming requests over HTTP and other protocols. Background
threads are needed to do things like service discovery, service monitoring,
rating, event processing, polling external systems etc etc. I bootstrap
this "background" functionality via a servlet with loadOnStartup and an
init function that would kick everything off. I was experimenting with
moving all this background code to be loaded and managed by CDI. As the
initial servlet init function is within a managed context I could inject
from there on into the code base to boot everything up. I was thinking of
using @Singleton/@ApplicationScope managed beans as a way of neatly
starting these background objects with @PostConstruct once and only once so
they could do their thing with executors in the background. My recent
issues with controlling @Singleton/@ApplicationScope objects in
circumstances with multiple skinny wars in a EAR lead me to rethink using
CDI and rather use good old Singletons where I can fully control the
lifecycle of the instance and be sure its background processing is only
started once. Instead of creating my own threads I'd prefer to use
ManagedExecutorService and ManagedScheduledExecutorService. It was easy to
get these when I could inject them but now with singletons and classes that
are being created outside of the managed context (i.e. with
Foo.getInstance() as opposed to @Inject Foo) I need to get them from JNDI
and this is where I hit this particular issue.
Paul
On 11 October 2017 at 01:46, agumbrecht <ag...@tomitribe.com> wrote:
> Properties are somewhat documented here:
> http://tomee.apache.org/admin/configuration/server.html - It's not totally
> obvious in your case that the property named here does what Romain
> describes, but please feel free to create a ticket on the jira here:
> https://issues.apache.org/jira/browse/TOMEE if you would like a better
> description.
>
> The managed executor is a way to start threads that the server will attempt
> to stop on a shutdown. The app server is already multithreaded, so there
> might be a better way to do what you are intending?
>
> Andy.
>
>
>
> -----
> --
> Andy Gumbrecht
>
> http://www.tomitribe.com
> agumbrecht@tomitribe.com
> https://twitter.com/AndyGeeDe
>
> TomEE treibt Tomitribe ! | http://tomee.apache.org
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-
> f979441.html
>
--
*Paul Carter-Brown*
*Group Chief Information Officer*
*Smile Communications Pty (Ltd) *
Smile +234 (0) 702 000 1234
Mobile +27 (0) 83 4427 179
Skype PaulC-B
paul.carter-brown@smilecoms.com
www.smilecoms.com
--
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
Re: DefaultManagedExecutorService lookup in JNDI
Posted by agumbrecht <ag...@tomitribe.com>.
Properties are somewhat documented here:
http://tomee.apache.org/admin/configuration/server.html - It's not totally
obvious in your case that the property named here does what Romain
describes, but please feel free to create a ticket on the jira here:
https://issues.apache.org/jira/browse/TOMEE if you would like a better
description.
The managed executor is a way to start threads that the server will attempt
to stop on a shutdown. The app server is already multithreaded, so there
might be a better way to do what you are intending?
Andy.
-----
--
Andy Gumbrecht
http://www.tomitribe.com
agumbrecht@tomitribe.com
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe ! | http://tomee.apache.org
--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
Re: DefaultManagedExecutorService lookup in JNDI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
You need to set openejb.environment.default=true. Idea is to skip resources
which uses machine resources by default to stay usable in all environments.
Alternative is to use a pool impl executing tasks synchronously bit would
quite useless IMHO.
Le 10 oct. 2017 23:13, "Paul Carter-Brown" <pa...@smilecoms.com>
a écrit :
> Hi,
>
> According to EE7 spec I should be able to do the following:
>
> try {
> new
> InitialContext().lookup("java:comp/DefaultManagedExecutorService");
> } catch (NamingException e) {
> log.warn("Error:", e);
> }
>
> In TomEE 7.0.4 I get a NamingException:
>
> javax.naming.NameNotFoundException: Name [DefaultManagedExecutorService]
> is
> not bound in this Context. Unable to find [DefaultManagedExecutorService].
> at org.apache.naming.NamingContext.lookup(NamingContext.java:816)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
> at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at com.test.beanmanagerbug.MyServlet.init(MyServlet.java:36)
> at javax.servlet.GenericServlet.init(GenericServlet.java:158)
> at
> org.apache.catalina.core.StandardWrapper.initServlet(
> StandardWrapper.java:1183)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(
> StandardWrapper.java:1099)
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:989)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(
> StandardContext.java:4931)
> at
> org.apache.catalina.core.StandardContext.startInternal(
> StandardContext.java:5241)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1419)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1409)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>
> Any idea how I can get the DefaultManagedExecutorService in an unmanaged
> bean (i.e. using JNDI)
>
> Thanks
> Paul
>
> --
>
>
> This email is subject to the disclaimer of Smile Communications at
> http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/
> disclaimer>
>
>