I'm trying to understand how I can use concurrency in the Tomcat environment.
I saw Spring official tutorials where #Async was used with spring-web dependency. So I gues that is is safe.
On the other hand, I've read JSR 236: Concurrency Utilities for Java EE which tells: "java.util.Timer, java.lang.Thread and the thread pool creation APIs from the Java SE concurrency utilities (JSR-166) in the java.util.concurrent package should never be used within managed environments, as it creates threads outside the purview of the container".
Trying to understand how #Async works I've found out that it is handled by AsyncAnnotationBeanPostProcessor that uses org.springframework.core.task.TaskExecutor extends java.util.concurrent.Executor.
May you explain why #Async is safe in a container servlet environment or suggest documentation that explains this aspect?
Thank you.
Related
I have situation where I need to perform certain tasks in case my springboot applications fails to start. Basically I want to release various resources. I tried using #PreDestroy annotation but it did not work as application was not started yet. Is there any way out by which we can perform few actions in case springboot application fails to start
Spring app heavily using threadpool context when start the program , so when the main program fail spring can not manage the standard beans related to spring. you can only start new thread using implements Runnable in main class and no access to spring resources as well , just simple getclassloader().getresourceasstream is available there .
However you can write independence java Agent using -javaagent to do some operation on release resource ,see java.lang.instrument.Instrumentation;
I'm trying to migrate a JEE service to Quarkus and wonder how to obtain a thread factory in a Quarkus app. Simply create one like javaExecutors.defaultThreadFactory(); as in JavaSE?
In a Java EE environment you would normally use a managed thread factory for creating threads for execution:
#Resource
private ManagedThreadFactory mtf;
Any idea how to do this correctly within a Quarkus app?
Addition: Using a ManagedExecutor is unfortunately not possible as some libraries like Apache HttpAsyncClient requires a ThreadFactory for it's configuration.
Unless you have a special use-case that requires creating actual Threads, I would recommend using an Executor instead of a ThreadFactory. This is typically better because you can submit lightweight work objects (Runnable/Callable/etc) to an Executor and it will run on the Executor's thread pool (which is managed by Quarkus), as opposed to creating heavyweight threads.
Quarkus provides support for MicroProfile Context Propagation, which is basically an extension of Java EE Concurrency. To use it, you can inject a ManagedExecutor like this:
import org.eclipse.microprofile.context.ManagedExecutor;
// ...
#Inject
ManagedExecutor exec;
I recently was fascinated by a migration scheme presented by the Talend http://coders.talend.com/
(I guess) via talk record here
and presentation from the talk made by Andrei Shakirin.
I'va seen a lot publications made by his colleague Christian Schneider as well.
And, of course, the part of the subject matter is Christian's blueprint-maven-plugin.
The presentation linked above says how it is possible to continuously deploy same code base to either common Java EE container like Tomcat and to OSGi container like Karaf which is exactly what I am interested in (not Tomcat but Wildfly or Glassfish for instance)
So, I wonder:
How blueprint-maven-plugin handles #Stateful, #Stateless annotations
and #ApplicationScoped, #SessionScoped, #RequestScoped etc. on beans
while producing blueprint file
Also, say I have a new code to write which would use CDI and I want that to be also deployable to Karaf. How should I then write
that piece? Should I avoid #Stateful, #Stateless annotations ?
How those annotations (if they for any reason irrelevant for the case when I deploy to OSGi) would be interpreted by that OSGi
container (Karaf) since those annotations DO present in the code ?
After a quick scan on the maven-blueprint-plugin source code. Seems like EJB annotations Stateless,Stateful and *Scope isn't handled by the plugin.
#Stateless and #Stateful isn't really part of CDI but an extension to it (EJB). If you really love what EJB do, consider using the OpenEJB feature in karaf. You should be able to do #Inject without these annotation as long as that is a valid bean.
Annotations are just a marker to source code (in other word, they don't do anything), it doesn't do anything unless there's a processor registered to handle them.
E.g. you can instantiate an EJB with new keyword and perform unit test on it (fulfill all injection with setter of course)
Disclaimer:
I don't really use this plugin myself, and there might be a newer version of plugin support these ejb annotations.
I want to run few tasks asynchronously in a web application. My question is which Spring implementation of task executors i should use in a Container managed environment.
I refereed to this chapter in Spring documentation and found few options.
One option I considered is WorkManagerTaskExecutor. This is very simple and works seamlessly with the IBM Websepher server which I'm currently using but this is very specific to IBM Websphere and Oracle Weblogic servers. I don't want to tie my code specifically to one particular implementation as in some test and local regions we are using Jetty container & this implementation creates problems to run the code in Jetty.
Other options like SimpleThreadPoolTaskExecutor does not seem to be best fit to leverage thread pooling in container managed environment and I don't want to create new thread myself.
Could you pleas suggest how do I go about this. Any pointers to a sample implementation will be great help.
As usual, it depends. If you rely on the container's thread management and want to be able to set thread pools on its admin interface or if you're application is not the only app inside the container or you use specific features like setting thread pool priorities for EJB or JMS you should add support for the WorkManagerTaskExecutor and make it configurable. If not, you can use whatever you want cause in the end threads are just threads. Since Spring is an IOC container you can do it. To use the same app everywhere I wouldn't suggest to change the XML config per app version. Rather
use profiles with configuration to set the executor type and inside your java config return the proper bean type. If you use Jetty you should have a configuration for the thread pool sizes to to be able to tune it.
use spring boot like auto configuration which usually rely on available classes on classpath (#ConditionalOnClass). If your weblogic or websphere specific classes are available or any other container specific thing like env variables you can create the WorkManagerTaskExecutor
With both of these you can deploy the same war everywhere.
I am using the following versions:
Spring 3.1.1.RELEASE
Netty 3.4.0.Final
Hibernate 3.5.6-Final
Now, I have a Netty server that works fairly well - the root of the server, the pipeline factories and the base "stub" of the server that owns everything are all set up with Spring. In this stub, spring #Transactional annotations work just fine.
However, in the handlers, which are stateful and created dynamically depending on what state the user is in - #Transactional doesn't work. I'm fairly sure I understand why. I even have a "solution" - but it's not very good.
After the decoders and encoders, I add an ExecutionHandler:
pipeline.addLast("execution", new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(16,1000000, 1000000)));
This appears to be where the Spring transaction support is breaking. Since Spring is unaware of these threads, it can't bind any transactions to them. The classes are proxied correctly, but in debug they have no associated transactions.
My solution is crappy, and it needs to be replaced by a real solution:
Session sess = SessionFactoryUtils.getSession(getSessionFactory(), true);
That's bad because it relies on me to release the session, and it may not even be transactional, I haven't checked. It sucks in a lot of ways.
Anyway - the root of the question. Given the above tech, what's my path to getting my #Transactional notations working on the Netty handlers?
Write an ExecutionHandler that's Spring aware?
NOTE: I can't upgrade to Hibernate 4, due to lack of compatibility with Spring-Flex, used in another project in the group. Probably the same story for the Spring version, can't remember.
I suggest you create these netty's handler inside spring container and inject the service or persistence layer into the handlers so you can have these layers independence from netty and of course these are old school spring beans.