I've got an app that creates a load of Daemon threads, I'd like each one to shut down when the app is shut down.
I'm a little worried thought that Websphere 7 might not be shutting them all down.
Does anyone know if Websphere 7 treats Daemons threads differently? (I know it should do)
Note:
I know what shouldn't create threads manually, and that I should probably use WebSphere WorkManager or something, but this app has to run in Tomcat and WebSphere.
I know that I should tie in all threads to some context/shutdown mechanism, this is in progress.
Each WAS server runs a single JVM, and daemon threads are tied to the JVM's lifecycle, not the app's lifecycle. Therefore, you should not expect any daemon threads to be shut down when your app stops.
As you've already indicated, you should not create threads manually; the Java EE specs forbid this and the behavior in a Java EE container is different than a standalone Java application as you've already found. Unfortunately, there is currently no Java EE standard for a WorkManager equivalent; however, JSR-236 (Concurrency Utilities for Java EE) may be back as a candidate for inclusion in Java EE 7.
In the meantime, on WAS, you can use the asynchronous beans (WorkManager). We have successfully used this method to tie threads to the application lifecycle.
However, since you need to run in another container as well (Tomcat), there may be some other options to consider handling concurrency in your applications:
CommonJ WorkManager
Servlet 3.0 Asynchronous Servlets
ServletContextListener to hook into the web app lifecycle
Some other potential options for handling concurrency include the following, but these require EJBs, which may not be available in Tomcat:
EJB 3.0 Timer Service
EJB 3.1 Asynchronous Beans
Here are a few related threads on the topic of concurrency in Java EE:
Replacing Websphere's WorkManager in JBoss?
Getting thread from Container?
As has been mentioned you're not supposed to do this, but there isn't a good way to do it. This hasn't caused any problems for me.
This approach requires centralized thread-creation and the use of a listener to terminate threads when the app is stopping.
You'll have to do a few things:
Centralize all thread creation in a single class (call it ThreadService). When a thread is created here put it in a list so you can later loop through the list to stop them all.
Make an interface that your threads implement that allows you to stop each thread via the same interface. Each thread you have has to implement it's own mechanism for handling this. For example if your Thread uses a loop and Thread.sleep() then set stopped=true and interrupt the thread. The loop should check this and break from the loop when stopped=true.
Make a listener and implement ServletContextListener. When contextDestroyed() is called call ThreadService.stopThreads(). Register this listener in web.xml.
Websphere is just a java application. It cannot respect or do not respect deamon threads that are the feature of JVM or java runtime environment. So, if you create deamon thread inside Java EE application it will be deamon in every application server.
Moreover as far as I know even if you create regular thread it will not prevent application server from shutting down: the shutdown mechanism of every application server tries to close all its components and in the end runs System.exit() to win the criminals :) that open threads manually.
Related
For simpler control over application performance I want to use one application wide thread pool. Our app uses Tomcat as web server, Spring and, on the lower level, makes a lot of calls to external APIs. I need some of this external calls run asynchronously, and want to use for this purpose same thread pool as Tomcat uses for client request service.
Firstly, I thought that I can somehow obtain Tomcat thread pool and then use it, but after some googling I haven't found a way to do it.
My second thought was to set custom thread pool for Tomcat and also use it in other places, where I need async calls. But I haven't found how to implement it also.
Any help and advice will be appreciated.
Choose task executor abstractions from Spring.
I am trying to build a webapp with a Vaadin frontend which lets a user upload and process data on our server. The process is quite complicated and is a multi-threaded app (let's call this the 'core'). Whilst designing this app, I thought I could stick everything onto the tomcat server but a colleague of mine told me that natively, Vaadin is RESTful and will thus not run the business process continuously because the application is stateless. He claims that the tomcat JVM will simply go to sleep after running the request and not complete the thread process. Therefore, he suggests that I use RMI to send the data to another process on the same server and process it there instead.
I have a few questions about this:
Is all that he's claimed true? There are some intricacies of implementing Vaadin on Tomcat that I'm not aware of?
More likely I think I'm misunderstanding him and he's actually explaining on why it's better to seperate presentation and business components (which I completely agree with). But on a purely theoretical point of view, would it be possible to stick the multi-threaded core onto the same tomcat server instance as the one running Vaadin?
As far as i know, Vaadin does not use REST services for client-server communication. It is stateful and uses some kind of backing beans.
Regarding your thread issue, if you call your long running task directly from a Vaadin component, it will block the thread processing your request until the task is done. From the browser point of view, you'll have to wait and see the spinning indicator until the process is done (or an exception due to request timeout is thrown).
What you can do is to run your long running task in a separate thread. If you want the new thread to run on the same JVM, you do not need something like RMI.
You can do it by either:
Use an ExecutorService (e.g.: Executors.newSingleThreadExecutor()) and submit a task into
Create a new thread and start it
Do something like: https://vaadin.com/forum/#!/thread/2008536/2010911
Note that you'll probably have to implement some kind of notification mechanism to know when the thread has completed the task.
You can start separate threads from tomcat as needed.
It does not matter what frontend you have for this.
But what's important is to access the vaadin UI components the correct way when you wish to update them from another thread.
For vaadin 7 this has been greatly enhanced, to allow server push out of the box.
In vaadin 6 you had to use some work arrounds for this.
https://vaadin.com/book/-/page/advanced.push.html#advanced.push.running
We use this concept a lot for export and report generation.
- Use click on Export/Report
- On the server we start a (low priority) thread which builds the report/export
- During this, we update a progressbar on the client via server push
- Once the thread has generated the export/report we send it to the webbrowser
If you wish to have a core running always and accepting "jobs" then perhaps you are better served with a job sheduler like quartz or similar.
I have a scenario to ask regarding utilizing the EJB Timer Service.
Use case as follows:
The system should be able to schedule a task that will poll/ask our subversion repository for files changes using some particular timestamp.
The idea is that whenever the scheduled task is about to run, it will execute command against a particular svn repository.
For this particular purpose, I will not call any external process but will use the 'pure' java way of using the SVNKit java library http://svnkit.com/
My only concern is this:
Is it a good idea to use the EJB Timer Service to execute task that will call external processes? My way will use a 'pure' java way but in other scenario such as calling a batch file/command line/external executable directly into the timer service logic.
I worry about the effects of server memory use/performance etc.
Is this a good idea?
The other thought that I am thinking is to just create a 'desktop' application in the server using client based technology such as SWT/Swing that will do the polling and then code the logic there but this will mean that I need to manage two applications. The 'desktop' app that will poll and the 'web' user interface that I will create in Glassfish.
I am leaning towards doing everything in the App server of my choice which is glassfish.
I have used EJB Timer before but it only calls against the database without calling any extenral service and it's just that this scenario came up so I raised a question here to gather more thoughts from those who have experienced doing this.
Any thoughts?
In theory, EJBs aren't supposed to depend on external I/O since it interferes with the container/server's management of bean instances, threads, etc.
In practice, this should work if you take precautions. For example:
isolate the function to its own EJB (i.e., a stateless session bean that only handles these timers) to avoid instance pooling issues
use timeouts while waiting for commands to avoid hung processes from hanging all server threads
ensure that you don't schedule timers so that you have multiple OS commands run simultaneously
Keep in mind that EJB 3.0 timers are persistent (vs EJB 3.1 timers, which have the option of being non-persistent), which means:
They can run on any server in a cluster. If you have multiple machines in your cluster, you need to ensure that they are all capable of running the command.
They survive server restarts. If you schedule a timer to run but the server crashes before it can, it will run when the server restarts. This can cause particular problems for interval timers (all missed timers will fire repeatedly) and if you don't carefully manage existing times (you can easily create redundant timers).
I have an independent JMS listening and Responding service.
I want to invoke it as a independent thread from the servet.
so that the thread's execution will continue even the servlet finishes its execution.
Is it possible?
(Thanks in advance for your kind help.)
Yes, you can do that (unless you are on App Engine or some other severely restricted platform).
Instead of just spawning a new thread directly from the servlet, consider using an ExecutorService, that you can create and shut down in a ServletContextListener (so that when the container decides to stop your application, it does not leave active background threads around that cannot be cleaned up).
We are deploying application in WebSphere cluster. Application is running his own never terminated threads that are checking some condition for example:
while(true){
logger.severe("Unterminated thread");
Thread.sleep(10000);
}
Problem is that after the application is stop(via wsadmin or admin console) in the WebSphere, only the servlets are unregistrated but
these threads are not kill and are still running. Is there any way how to kill this treads when i am stopping the application? We are using WebSphere 7.
thanks
You should never manually create threads from JavaEE application. Thread management is something that should be provided by JavaEE container.
WebSphere has a WorkManager mechanism to assist you with you threading needs. Please look at this tutorial for implementation details.
Based on your comments to another answer, I have a suggestion. (Note, I agree with Oleg that you really shouldn't be doing it this way, but if you must...).
I presume that in the regular Java application that this code is from, these background threads somehow receive a signal to stop. What I would suggest is using a ServletContextListener to send the stop signal when your servlets have all been deregistered.
Note that if you don't already have some way to tell the threads to stop, that's probably another bug, and this won't help at all.