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).
Related
On the Springboot-based application, I am creating a thread to finish a batch job and returning back immediately. Now, I need to forcefully kill the thread in some scenarios like a timeout.
Can anyone help me to fix this use case?
If you're using Java's Executors Framework, you can simply use shutDown() method.
Otherwise, you can send an interrupt signal using Thread.interrupt() after your task is completed.
You can use Javamelody monitoring tool integrated in your application which provides you a nice dashboard of all the current running thread and a kill button to terminate the thread. This tool is extremely easy to integrate in Spring Boot applications - you just need to include couple of dependencies in your build file. Also you would like to protect the dashboard endpoint with some authentication - javamelody provides you with basic auth feature as well.
Another DIY way is to create an endpoint in your application to return thread id for the batch process ( you would need to give some meaningful name to tth thread group to differentiate it from other threads) and another endpoint which takes in thread id as parameter and can stop/kill the thread.
I'm currently working on an app which is heavily connected to maps. To display a map, we are generating a bunch of tiles in many threads, store them and get them if a user wants to see a certain part of the map.
The problem is, I'm naming threads that generate tiles a certain way, but then, when I want to get tiles to show a map, my servlet container's taking random threads from the pool, so the thread named for generating a tile ends up getting it from the storage. Of course, I could just rename the thread after generating a tile back, but I wonder if there is an alternative.
I wonder if I somehow can configure my servlet container for it to maybe kill threads after some time being idle or to create a new thread where I want to or to allocate several threads to work with this part of the code?
All I could find in terms of configuring servlet container is setting its min and max thread pool size, which I think won't help me.
The container is 100% in control over it's threading.
If you are attempting to manipulate the threading of the container then you are fighting a losing battle.
It is not possible to safely kill or stop threads on a running container, as this is incredibly unsafe, and will lead to many memory issues (leaks) and unclosed resources. The Thread.stop() method has been deprecated since Java 1.2.
Now that we have the negatives out of the way ...
Jetty is a 100% Async Java Web Server.
The classic assumption that 1 request uses 1 thread is wrong. (if you want this kind of behavior, then you should use Jetty 6 or older. Jetty versions older than 9.2 are now all EOL / End of Life)
When you use a Servlet call that is traditionally a blocking call, the Jetty server has to fake that blocking call to satisfy the API contract.
Even if using old school / traditional blocking Servlet APIs you'll still experience many situations where that 1 request has been handled by multiple threads over the lifetime of that 1 request.
If you want to work with the Servlet API and it's container then the first thing you should do is start to use both the Servlet Async Processing APIs and Servlet Async I/O APIs combined. Make sure you read about the gotchas on both APIs!
Async Processing will allow you to handle more processing of requests on the server side, not use the container threads that heavily, allow more control over how the threading behaves, will grant you better control over request timeouts, and even get notified of request/response error cases that you will always deal with on a web server.
Async I/O will allow you to only use a thread if there is content from the request/connection to read or if the connection allows a write. That connection will not consume a thread unless I/O is possible. This means more connections/requests per server, and ill behaving clients (slow, dead, problematic, etc) will not impact the behavior of your other clients by consuming threads that are not doing anything productive for you.
If you don't want to work with the Servlet API and do things your own way, then you'll have to manage your own Executor / ThreadGroup / ThreadPool that the server is unaware of. But that still means you'll need to use the Servlet Async Processing APIs to allow the 2 to coexist in harmony (you'll need to use the AsyncContext to inform the container that you are now taking control over the processing of the request, and then later inform it via the AsyncContext that you are done and the request is complete).
The biggest gotcha with this approach is that you cannot safely write to the HttpServletResponse from a thread that the container wasn't in control over.
Meaning the container dispatched on a thread to your application, that thread is the only one that can safely use the HttpServletResponse to write the response. You can have a different thread do the processing, a different thread provide the data to the HttpServletResponse, even a different thread that pumps the dispatch thread with content. But that thread you were dispatched to needs to be used to write.
This is the mixed threading behavior gotcha in the servlet spec. (you are in servlet async mode, on a different thread to process, but not using async mode to read/write.) It's a terribly complex, and ill defined, behavior in the servlet spec that leads to many issues, and I advise you to not chase this path.
This gotcha goes away if you also use the Servlet Async I/O APIs, but at that point the difference in the two above choices is negligible.
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 would like to ask what is the best approach to run a long process from a java servlet. I have a webapp and when the client do a request it runs a servlet. This servlet should get some parameters from the request and then runs a process. This process may take a long time so I need to run it separately. When this process executed finish, it send an email with the results.
Thanks in advance.
Use a thread pool. Each time you receive a request, create a task and submit it to the thread pool. This will ensure too many requests don't bring the server to its knees, because you'e in control of how many concurrent threads you can have, and how many tasks can wait in the thread pool's queue of waiting tasks.
See the javadoc for Executors and ThreadPoolExecutor.
Though this sounds a bit dangerous that invocation of a servlet spawns a process (without proper throttling capabilities in place), you can spawn a process using Runtime.getRuntime().exec(). Much better would be to use ProcessBuilder to prepare the process arguments and spawn it.
Normally that kind of activities is delegated to another type of application module like a message driven bean and that seems to be the cleanest, and standards compliant solution to me. Although most servers won't complain if you create your own threads (which is forbidden by the standard but rarely enforced) the amount of management needed to set up your own job queue and pooled execution environment isn't really worth it in my opinion.
I see two possibilities to do this:
Create a separate thread for each task (thread pool approach). This is possible, but potentially may create a performance problem.
Create a second application. For instance you can save parameters to DB. Second application will monitor this DB with some interval and do something. Instead DB you can use some message queue manager like WebSphere MQ
Second approach have the advantage: if app not able to process the request now by some reason, the app can return to it later
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.