I have a Weblogic 10.3 server and an ear application deployed on it.
I want that one of the servlets (that this application uses) always will have free threads to perform requests. Can I set for this servlet a separate thread pool? Or can you advise me something else?
Thank you,
Alex
Figured it out by myself.
I needed to define a workmanager in weblogic.xml of my application and in web.xml I needed to apply the new workmanager to my servlet.
More about creating and using workmanagers in WebLogic:
http://docs.oracle.com/cd/E23943_01/web.1111/e13701/self_tuned.htm#CNFGD117
http://www.itbuzzpress.com/weblogic-tutorials/weblogic-pools-configuration/using-workmanagers-in-your-applications.html
Related
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 am trying to understand the karaf thread model.
from what i can understand in OSGI in case the bundle starts threads it is also responsible for closing them.
is this the case in karaf as well?
are there any other solutions for managing threads in karaf?
Taken from the extra comment.
No the OSGi framework will not manage your threads.
If you spawn threads from your bundle, you are supposed to take care of it.
For example in the stop Method of your Activator you can stop the thread pool you used.
Threads in OSGi work like in plain Java. So for example you can use Executors.
I'm trying to execute subprocesses from within my application server (Glassfish 3.1.2)
Therefore I discovered the Apache Commons Exec library. The problem is that this library creates threads which should not be done on an application server because the server is not aware of these threads.
What could be a solution to this problem?
Would it be possible to create a message component written in Java SE who consumes messages containing information about pending jobs and register it with the application server?
The application server would then not have to deal with runtime exceptions and threads but just consume messages which contain the result or an exception.
Do you have any better ideas?
You could either use:
MDB (as pointed by duffymo),
Servlets 3.0 asynchronous processing,
Asynchronous EJB invocation.
Effectively, it should give you similar functionality as plain subprocesses.
Using Java SE component which communicates with Java EE just to overcome using threads on your own sounds a bit like an overkill. Just read about mentioned solutions and try if any of them fits your needs.
Message driven beans were designed for asynchronous processing. It could be a solution to your problem. You can create a separate listener thread pool sized to handle the traffic.
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