Hazel cast creates a number of threads. If my application is deployed in a j2ee environment, creating threads is discouraged. Is there a way to enable hazelcast to use application server managed threads?
There is no way to do that and there are no plans to make that happen.
Why do you think that app servers don't like you creating threads? I have done on quite a few and never had problems.
Related
Pure curiosity, I'm just wondering if there is any case where a webworker would manage to execute a separate thread if only one thread is available in the CPU, maybe with some virtualization, using the GPU?
Thanks!
There seem to be two premises behind your question: firstly, that web workers use threads; and secondly that multiple threads require multiple cores. But neither is really true.
On the first: there’s no actual requirement that web workers be implemented with threads. User agents are free to use processes, threads or any “equivalent construct” [see the web worker specification]. They could use multitasking within a single thread if they wanted to. Web worker scripts are run concurrently but not necessarily parallel to browser JavaScript.
On the second: it’s quite possible for multiple threads to run on a single CPU. It works a lot like concurrent async functions do in single threaded JavaScript.
So yes, in answer to your question: web workers do run properly on a single core client. You will lose some of the performance benefits but the code will still behave as it would in a multi core system.
I have been using Tomcat for a long time, and I am frustrated with the lack of control over threads. Some threads may eat up all the resources of the server, and that can't be controlled in Tomcat.
I'm exploring more advanced JavaEE containers like WebSphere, WebLogic, and JBoss. Do they allow controlling or changing the priority of a thread, or a group of threads, even manually? Furthermore, would they allow controlling the amount of CPU used by a thread?
Thanks,
Luis
Read the following artical on Weblogic Server:
Thread Management
WebLogic Server Performance and Tuning
This question is rather broad.
There are threads created by the container and there are threads created by applications. Tomcat thread priorities can be changed statically through configuration.
However you have no control over those created by applications unless they have made use of the javax.enterprise.concurrent facilities that have been added to Java EE 7. Different implementations of this may or may not provide a way of dynamically reconfiguring threads created in this way.
Some Java EE implementations prior to 7 may provide vendor dependent APIs for applications to get access to concurrent capabilities.
i have a webapp written with spring 3 and struts 2 that is hosted on a glassfish server. In this app i have two webservices that need to do some background work without delaying the accessed method response.
So, now i use a spring bean that uses an instance of org.springframework.core.task.TaskExecutor and from there i run my new thread.
Is this the correct/best practice approach in context of using this app on glassfish? or should find another method of doing this ?
It's discouraged to create your own threads because the app server is meant to be in charge. See the answers to Why is spawning threads in Java EE container discouraged?
However in practice, especially if it's the only application on there, you might be OK, especially if you use a fixed thread pool. Be sure all the threads are gone when you undeploy the app. (I expect Spring classes will handle disposal on undeploy / shutdown correctly, if you declare them within the Spring container).
I have a traditional 3-tier application with spring. One of my repositories needs > 3 minutes for initialization so I thought about some multi-threaded approach in order to speed up the whole process - I think most service and controllers in my dependency tree can already be started so only a few must wait for the last repository to come up.
Is there any best practice approach?
Use Spring's Executor abstraction. And if you are within a app server then I suggest you use application server's work-manager (spring supports it). For e.g. WebSphere app server and Weblogic both support registering the workmanagers in JNDI. You can then pass the jndi name to spring. Task Executors
are there any performance limitations using IBM's asynchbeans?
my apps jvm core dumps are showing numerous occurences of orphaned threads. Im currently using native jdk unmanaged threads. Is it worth changing over to managed threads?
In my perspective asynchbeans are a workaround to create threads inside Websphere J2EE server. So far so good, websphere lets you create pool of "worker" threads, controlling this way the maximum number of threads, typical J2EE scalability concern.
I had some problems using asynchbeans inside websphere on "unmanaged" threads (hacked callbacks from JMS Listener via the "outlawed" setMessageListener). I was "asking for it" not using MDBs in the first place, but I have requisites that do not feet MDB way.