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.
Why does being thread safe matter in a web app? Pylons (Python web framework) uses a global application variable which is not thread safe. Does this matter? Is it only a problem if I intend on using multi-threading? Or, does it mean that one user might not have updated state if another user... I'm just confusing myself. What's so important with this?
Threading errors can lead to serious and subtle problems.
Say your system has 10 members. One more user signs up to your system and the application adds him to the roster and increments the count of members; "simultaneously", another user quits and the application removes him from the roster and decrements the count of members.
If you don't handling threading properly, your member count (which should be 10) could easily be nine, 10, or 11, and you'll never be able to reproduce the bug.
So be careful.
You should care about thread safety. E.g in java you write a servlet that provides some functionality. The container will deploy an instance of your servlet, and as HTTP requests arrive from clients, over different TCP connections, each request is handled by a separate thread which in turn will call your servlet. As a result, you will have your servlet being call from multiple threads. So if it is not thread-safe, then erroneous result will be returned to the user, due to data corruption of access to shared data by threads.
It really depends on the application framework (which I know nothing about in this case) and how the web server handles it. Obviously, any good webserver is going to be responding to multiple requests simultaneously, so it will be operating with multiple threads. That web server may dispatch to a single instance of your application code for all of these requests, or it may spawn multiple instances of your web application and never use a given instance concurrently.
Even if the app server does use separate instances, your application will probably have some shared state--say, a database with a list of users. In that case, you need to make sure that state can be accessed safely from multiple threads/instances of your web app.
Then, of course, there is the case where you use threading explicitly in your application. In that case, the answer is obvious.
Your Web Application is almost always multithreading. Even though you might not use threads explicitly. So, to answer your questions: it's very important.
How can this happen? Usually, Apache (or IIS) will serve several request simultaneously, calling multiple times from multiple threads your python programs. So you need to consider that your programs run in multiple threads concurrently and act accordingly.
(This was too long to add a comment to the other fine answers.)
Concurrency problems (read: multiple access to shared state) is a super-set of threading problems. The (concurrency problems) can easily exist at an "above thread" level such as a process/server level (the global variable in the case you mention above is process-unique value, which in turn can lead to an inconsistent view/state if there are multiple processes).
Care must be taken to analyze the data consistency requirements and then implement the software to fulfill those requirements. I would always err on the side of safe, and only degrade in carefully analyzed areas where it is acceptable.
However, note that CPython runs only one thread context for Python code execution (to get true concurrent threads you need to write/use C extensions), so, while you can get a form of race condition upon expected data, you won't get (all) the same kind of partial-write scenarios and such that may plague C/C++ programs. But, once again. Err on the side of a consistent view.
There are a number of various existing methods of making access to a global atomic -- across threads or processes. Use them.
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.