I am working on a on Spring web service which calls a thread for a long running task, as I don't want to keep the user busy because the task can be really long.
I want to notify the user through web socket when the task on the thread has completed. What is the best procedure to do so in spring??
Spring websocket can be used for this purpose.
I beleive this would help you initially at least. https://spring.io/guides/gs/messaging-stomp-websocket/
Related
I'm learning about threads and how threads work when building a web application.
As per my understanding the flow is as follows:
User sends Http request
Tomcat creates a thread running the controller.
Spring boot runs an async annotated method, that runs code on a seperate thread pool created by the spring boot app.
The tomcat thread is released until the async method is completed to handle more requests.
Am I correct in my understanding?
Does spring boot create its own thread pool to run async operations on freeing the main tomcat thread?
When the asynchronous method is called, the tomcat thread isn't "released" or "freed". It proceeds with the next instruction after the async method call and keeps on going (unless it does something like call get on a future returned by the async method so that it blocks until the future completes). Both threads execute concurrently.
It is true that Spring has its own separate threadpool that it uses for async methods. The Executor used is configurable, #Async takes the name of the executor as an argument so different methods can use different pools if needed. And Tomcat has a pool for its threads, of course.
I have a question, I am just starting on reactive programing and I am using quarkus. I made a demo with Panache hibernate reactive and one with SQL clients.
I want each of my rest apis to run on a different non blocking thread. With panache hibernate whenever I did a a blocking action I got a message about it and in the logs it showed me that the api was running o vertex event loop thread so everything was fine.
In Reactive clients everything runs on executor thread 0 does that mean my apis aren’t asynchonus(reactive) from input to output and when I run a blocking action non erros is showing.
Quarkus tries in a lot of places to put the proper guard-rails when it comes to the threads that can be used - however it can't catch all mistakes.
If you are seeing your code executed on a thread that has executor in the name, then the request is being serviced by the wrong thread pool.
If you are using quarkus-resteasy for example, this is the only way that RESTEasy can handle requests - it doesn't matter what your code is, the request is always handled on an executor thread.
For this reason, Quarkus provides RESTEasy Reactive (which is the prefered REST API layer) which allows you to choose whether you want a request to be serviced on an executor thread or an event-loop thread.
See this for more details.
For a while now, our team started to work on a reactive new micro-service. The service is mainly using spring-webFlux and other cool reactive futures.
At this point there should be created a cron-job triggered every 10 secs(that has to verify some transactions state), but I'm afraid that this will affect the load of the app and also is not compatible with the reactive concurrency model since the #Scheduled job when will be triggered it's going to consume one thread until it ends.
At this point I'm more in favor of an aws-lambda that it's going to call an endpoint of our app.
Do you have any better suggestions or advices ?
You can't schedule an AWS Lambda to run more often than once a minute. If you need an event to occur every 10 seconds in Spring I think using #Scheduled is your best option.
I have built a batch job which is called from enterprise scheduler to access a light-4j microservice to perform some daily tasks. The batch job is a standalone application uses the light-4j client module to invoke the microservice.
A strange thing happens after the job is done. The main class does not exit automatically after the job is done. It looks like there are still some threads running that prevents the main class to exit. When I switch the light-4j Http2Client to Apache HttpClient, the main class exits gracefully. Am I doing something wrong?
Unlike other Http Client which is single-threaded. The light-4j Http2Client is using an event loop to handle multiple requests/responses asynchronously like the Undertow Server. This ensures the highest throughput and lowest latency; however, the event loop allocated a thread pool that won't be closed after the main thread is completed. This requires to call system.exit() to stop the JVM application. After that, all running threads from the application will be stopped.
Here is an example of standalone applications that uses Http2Client.
https://github.com/networknt/light-example-4j/blob/release/client/standalone/src/main/java/com/networknt/client/Http2ClientExample.java#L56
I need to fire off a long running batch type job, and by long we are talking about a job that can take a couple of hours. The ejb that has the logic to run this long running job will communicate to a NoSQL store and load data etc.
So, I am using JMS MDBs to do this asynchronously. However, as each job can potentially take up to an hour or more (lets assume 4 hours max), I dont want the onMessage() method in the MDB to be waiting for so long. So I was thinking of firing off an asynchronous ejb within the onMessage() MDB method so that the MDB can be returned to the pool right after the call to the batch ejb runner.
Does it make sense to combine an asynchrous ejb method call withing an MDB? Most samples suggest using 1 or the other to achieve the same thing.
If the ejb to be invoked from the MDB is not asynchrous then the MDB will be waiting for potentially long time.
Please advise.
I would simplify things: use #Schedule to invoke #Asynchronous and forget about JMS. One less thing that can go wrong.
Whilst not yet ready for prime time, JSR 352: Batch Applications looks very promising for this sort of stuff.
https://blogs.oracle.com/arungupta/entry/batch_applications_in_java_ee
It's a matter of taste I guess.
If you have a thread from the JMS pool running your job or if you have an async ejb do it, the end result will be the same - a thread will be blocked from some pool.
It is nothing wrong with spawning an async bean from a MDB, since you might want to have the jobs triggered by a messaging interface, but you might not want to block the thread pool. Also, consider that a transaction often time out by default way before an hour, so if you do MDB transactional by some reason, you might want to consider fire of that async ejb inside the onMessage.
I think Petter answers most of the question. If you are only using mdb to get asynch behaviour, you could just fire the #Asynchronous asap.
But if you are interested in any of the other features your JMS implementation might offer in terms reliability, persistent queues, slow consumer policies, priority on jobs you should stick to mdb:s
One of the reasons behind introducing #Asynchronous in ejb 3.1 is to provide a more lightweight way to do asynchronous processing when the other JMS/MDB features are not needed.