I need to set up an HTTP connection pool in a Spring app on a Tomcat server.
We are debating whether to define the pool at the application or at the server level (applicationContext.xml vs server.xml).
My problem is: I've looked and I've looked, but I just can't find any info on doing either.
For now, I'm working with org.apache.http.impl.conn.PoolingClientConnectionManager inside my class, and it's working ok.
How would I be able to define a pool outside my Java code and work with it from there?
Here is the configuration reference you are looking for for tomcat 7:
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation
Here is also another SO post on the same subject: How to increase number of threads in tomcat thread pool?
Related
I'm using a cloud database at elephantsql.com. As I'm using a free plan I can have only 5 concurrent connections.
I have a spring boot application that connects with this cloud database. The problem is that even when there is just one user at the website the spring boot application opens a lot of connections and some times it exceed the 5 connections.
I checked the connections at elephantsql.com and got this:
Its seems that the following unnecessary query is increasing the amount of connections...
SET application_name = 'PostgreSQL JDBC Driver'
How could I fix this to avoid the application to open unnecessary connections?
The setting you're looking for is probably
spring.datasource.max-active=5
Default value of this property is 10.
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.
I am using spring boot 2.0.4.RELEASE. My doubt is whether my application is running in event loop style or not. I am using tomcat as my server.
I am running some performance tests in my application and after a certain time I see a strange behaviour. After the request reaches 500 req/second , my application is not able to serve more than 500 req/second. Via prometheus I was able to figure out max thread for tomcat were 200 by default. Looks like all the threads were consumed and that's why , it was not able to server more than 500 req/second. Please correct me if am wrong.
Can the tomcat server run in event-loop style ?
How can I change the event-loop size for tomcat server if possible.
Tried changing it to jetty still the same issue. Wondering if my application is running in event loop style.
Hey i think that you are doing something wrong in your project maybe one of your dependency does not support reactive programming. If you want to benefit from async programing(reactive) your code must be 100 reactive even for security you must use reactive spring security.
Normally a reactive spring application will run on netty not in tomcat so check your dependency because tomcat is not reactive
This is more of a analysis. After running some performance test on my local machine , I was able to figure out what was actually happening inside my application.
What I did was, ran performance test on my local machine and analysed the application through JConsole.
As I said I scheduled all my blocking dB calls to schedulers.elastic. What I realised that I it is causing the bottleneck. since my dB connections are limited and I am using hikari for connection pooling so it doesn’t matter the number of threads I create out of elastic pool.
Since reactive programming is more about consuming resource to the fullest with lesser number of threads, since the threads were being created in unbounded way so it was no different from normal application .
So what I did as part of resolution limited the number of threads to 100 that were supposed to be used by for dB calls. And bang number jumped from 500 tps to 2300 tps.
I know this is not the number which one should expect out of reactive application , it has much more capability. Since right now I do not have any choice but to bear with non reactive drivers .Waiting for production grade availability of reactive drivers for mssql server.
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.
My application stack consists of Spring MVC, Hibernate and MySQL hosted on Apache tomcat 7.
I have set up Spring to manage transactions and Hibernate session factory is utilizing the tomcat dbcp connection pool backed datasource for getting the connection.
I have a use case in my application in which I have a run a long running task which is initiated through the web UI (say a button click). This task runs for let’s say 10 minutes then my connection pool starts to throw connection closed exceptions. This is obviously because of connection pool setting in which if the connection is not returned to pool after a specific time, it is marked as abandoned and later removed. I could solve this by tinkering with the timeout settings and increasing it to a large enough value. But I may have several other use cases like this and may not currently have idea how long those will run.
So I am thinking of another approach here.
This use case will be initiated not very often, so I may use a separate datasource definition without using connection pool. Of course I can set two transaction managers in Spring with different names “abc” and “xyz” and use the #Transactional(name=”abc”) and #Transactional(name=”xyz)”. Both these transaction managers would use their respective datasources – one with connection pool to support common use cases and one without connection pool to support long running transaction. This way I won’t have to worry about changing the timeout configurations.
Will this be a generally accepted solution or should I take the timeout configuration approach?
Avoiding to use the connection pool will cause problems if you don't have another way to limit the number of connections that your application can initiate. For example (trivial example of cours) if your going to launch your batch process each time a user clicks a button, make sure you limit the times they can do this task.
Another way would be to define a new jdbc resource in your application server (jdbc/batchprocess) and configure in this resource a longer timeout. Then change from one to another using dynamic datasource routing.
You can open Hibernate Sessions, supplying your own Connection:
sessionFactory.withOptions().connection( yourConnection ).openSession();