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;
Related
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.
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 am trying to create a standalone database application which can offer CRUD operations to other applications/modules...
I am aware of the need to create the entities and services used by the application in another artifact since you cannot depend on a spring-boot application alone.
But, can one get the runtime spring-configuration of a spring-boot application? So one can access a service that is deployed on my application?
For best through-put I am looking for a way to use services on a running spring-boot database application on the same JVM in order to minimise overhead...
RMI
What you want is technically it is possible using basic Java RMI (remote method invocation), you just register the bean as the implementation instance and share the interface between the two JVMs, either on localhost or even on different machines.
Spring even gives some additional support for this using RmiProxyFactoryBean, see Spring Remoting RMI article.
From above article, you can export it, using:
#Bean
RmiServiceExporter exporter(CabBookingService implementation) {
Class<CabBookingService> serviceInterface = CabBookingService.class;
RmiServiceExporter exporter = new RmiServiceExporter();
exporter.setServiceInterface(serviceInterface);
exporter.setService(implementation);
exporter.setServiceName(serviceInterface.getSimpleName());
exporter.setRegistryPort(1099);
return exporter;
}
and import it, using:
#Bean
RmiProxyFactoryBean service() {
RmiProxyFactoryBean rmiProxyFactory = new RmiProxyFactoryBean();
rmiProxyFactory.setServiceUrl("rmi://localhost:1099/CabBookingService");
rmiProxyFactory.setServiceInterface(CabBookingService.class);
return rmiProxyFactory;
}
Then you can use it in your application context based on your interface.
However I would not suggest to share beans like this because it has the same problem RMI has.
Shared library
Another way to do what you want is to create a shared library that can be included in other projects.
If all the project, which want to use it are Spring Boot application you can create a Spring Boot starter, see Spring documentation.
This way, other applications just have to add the dependency and they already has access to the beans in their application context, as well as the shared domain objects.
If other application use just regular Spring, they can just #Import your main configuration class.
If other apps are using Java, but not Spring, you can still use Spring inside, just provide a factory, which creates an internal Spring context.
REST service
If other applications are not written in Java, your best bet is to expose a REST interface for them to use the database applications.
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'm new to OSGI and working on such project that runs on websphere.
I have a simple scheduler, I used java.util.concurrent.ScheduledExecutorService like so:
private ScheduledExecutorService scheduler;
...
scheduler = Executors.newScheduledThreadPool(corePoolSize);
since my application is running inside a container(WebSphere) I though it will be better to let the container manage the threads, so I wanted to use:
scheduler = Executors.newScheduledThreadPool(corePoolSize, threadFactory);
were threadFactory will be injected in the blueprint from the container.
I've looked around and could not find an example of how it can be done.
So my question is, how can it be done and is it worth the effort at all?
I have found some very useful resource regarding my question,
accurding to this:
http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4
Other packages, such as quartz and the JDK Timer, start unmanaged
threads and should be avoided.
the solution is:
http://www.ibm.com/developerworks/websphere/techjournal/0606_johnson/0606_johnson.html#sec5
a sample code is available, basically a custom TheardFactory is implemented using WebSphere WorkManager and than all left to do is initiate ExecutorService with the custom ThreadFactory.
I am not sure where the OSGi tags comes in from this particular case, but there are several links off of this question that you will find useful. I would not use the WorkManager stuff in the article cited in your own answer, as it is very IBM specific and there is a better alternative in the commonj API and for that matter, there is a Timer service as part of the API that may take care of your needs altogether.
If you use Spring, then you can code their integration for task execution and scehduling, which supports the JDK and commonj transparently (at compile time).