We have springboot microservice running on liberty server. We have liberty configured with executor threads core and max size, in parallel can we also have callable implementation on the service to make a maximum utilisation of machine? or will it have counter effect?
You should be able to instruct Spring to use Liberty's default managed executor (which runs tasks on the Liberty thread pool) by supplying a DefaultManagedTaskExecutor to the Spring AsyncSupportConfigurer.setTaskExecutor method.
This will cause Spring to look up java:comp/DefaultManagedExecutorService which is available in Liberty if you enable the concurrent-1.0 feature.
This page has an example of setting the task executor in Spring, except it uses a custom thread pool, and you would replace that with DefaultManagedTaskExecutor:
https://howtodoinjava.com/spring-boot2/rest/async-rest-controller-callable/
Related
I recently read an article regarding Tomcat architecture and a high level overview of its working and monitoring.
Key metrics for monitoring Tomcat - DataDog
In this article, it mentions Tomcat having a pool of worker threads per connector that can be configured.
It also mentions about Executors and how it is mainly a thread pool that is shared with multiple connectors.
I have some doubts regarding Spring Boot and its Embedded Tomcat Server
How many Connectors are configured by default for this embedded Tomcat Server?
Does the embedded Tomcat have an Executor configured? Or is it just the basic pool of worker threads.
I can see that we can configure the accept count using application.properties by using the following property
server.tomcat.accept-count
I believe acceptCount sets the max number of connections that can be queued up in the OS level queue when no worker thread is available. ( As per the mentioned article )
Does this mean that there is no Executor configured for the default Connector? If there is, how do we configure the queue size of that executor?
I would be grateful if someone could shed some light on the above.
In short, I just wanted to know if the server configuration via application.propeties is for an Executor or for the Connector specific pool of worker threads.
We are doing some performance testing of our application which uses SpringBoot 2.2.2 with Spring Actuator.
We want to monitor:
How many tomcat threads are being used
How many tomcat requests are being queued
How many ThreadPoolTaskExecutor threads are being used (we are using #Async with a threadpool for some of the tasks)
Is this information available in the actuator? I couldn't see which metrics I needed to use.
By enabling Tomcats MBean Registry you will get more metrics collected, including thread pool metrics:
server.tomcat.mbeanregistry.enabled=true
I am working on a project where we are planning to use WLP (WebSphere liberty) instead of traditional WAS.
The code is using WAS scheduler for scheduling activities.
Does liberty also have the same level of support/features for scheduler as present in WAS .
How can I migrate the scheduler tasks from websphere to liberty?
Code using the Scheduler in traditional WebSphere Application Server should not be migrated to EE Concurrency Utilities unless you are certain that you do not need the transactional/persistent quality of service that the Scheduler provides (Scheduler tasks run in a transaction and can roll back and be retried, and they can also persist across server restart). To obtain a similar quality of service in Liberty, you should migrate your Scheduler tasks to Persistent EJB Timers. Note that while fail over support across multiple servers is not present in Persistent EJB Timers in Liberty at the time of writing this, it is currently being worked on.
In order to control the amount of threads on the jetty main embedded server I load a EmbeddedServletContainerCustomizer using the #Component annotation. Im using a different port for the management context and so it seems that a different jetty instance is executed for that port. How can I do the same process for that port or Jetty instance?
Regards
Bruno
Just found out how to solve my issue.
Using the application properties
server.jetty.acceptors
server.jetty.selectors
I can control the amount of threads on both ports. It is not very customisable but it gets the job done. For the main service port, configuring with a EmbeddedServletContainerCustomizer will override these configurations.
Regards
Could you run Spring Batch inside a Java EE server (eg. WebLogic), let's say as a Web Application? Is there any issue with Spring Batch creating more threads (for multi threaded steps and parallel steps) inside a Java EE server? Is this creation of threads by the framework against Java EE specification?
I am thinking it is okay and people are doing this after reading the following link
http://static.springsource.org/spring-batch/reference/html-single/index.html#runningJobsFromWebContainer
Please help.
This is an old question, but I will add an answer after all.
Yes, there may be some problems. I encountered such problems on WebSphere server.
According to their documentation: http://www-01.ibm.com/support/docview.wss?uid=swg21246676
Using a Java™ call such as "newThread()" to spawn a new thread is not
supported according to the J2EE specification. This spawned thread
does not inherit the J2EE context. What is recommended to do instead
is to use an asynchronous bean or Commonj WorkManager thread. These
threads have a proper J2EE context and support an indirect JNDI
lookup.
Spring batch creates it's own threads using new Thread, and these threads do not inherit J2EE context.
In my specific case one of Spring Batch Job consumed a few REST services over https, and it turned out that threads spawned by Spring Batch don't see https cerificates installed in WebSphere server, causing certificate's errors.
I see no issue here.
Spring Batch (like Quartz Scheduler) runs as a Web Application, it is not bound by the prohibition to create threads, which applies only to EJB components (not to Servlets).
So, provided you do not exceed the server capacity limits, Spring Batch can run in any EE application.
It is a common practice. The book Spring Batch In Action Chapter 4.4 discusses the exact same scenario, launching the batch job from the web container. The batch job should be run within a thread pool with N threads. The number of threads in the pool should be determined by the throughput result of performance load test.