What is the benefit of using evictInBackground operation on ConnectionProvider which is used with HttpClient.create(connectionProvider) in springboot webflux ?
By default, the connection pool timeouts (maxIdleTime, maxLifeTime etc.) are checked on connection release or acquire operations and, if some timeout is reached, the connection is closed and removed from the connection pool. However, you can also configure the connection pool, by setting evictInBackground, to perform periodic checks on connections.
The configuration evictInBackground is often combined with disposeInactivePoolsInBackground to remove from the structures all inactive connection pools.
Related
I am creating an ETL application where I actually need a large number of concurrent connections running long slow queries. It is not uncommon to see the number of concurrent connections to be as large as 100 depending on the machine running the application.
Let's assume it takes about 2s to establish a connection with the database. If I don't use pooling and parallelize connection retrieval with 100 threads then all connection are still established in about 2s. However, while using HikariCP I've noticed that time to establish 100 connections at the start of the application when there is a spike in connection requests, it takes about 200s to establish all connections and often results in timeout.
This drives me to the conclusion that obtaining a new connection is a blocking call. Also it seems that hikariCP pool is lazy initialized and I assume that once it establishes all 100 connections it will try to keep the pool size at 100.
Is there a way to enable more concurrent behaviour of establishing connections in hikariCP? Could I at least force it to concurrently initialize (establish 100 connections) the pool?
One could say that the time to initially establish all connections is irelevant in the lifetime of the application, but I also want to have timeout set to 30seconds which will always result in timeout exception during initial spike demand.
I am calling org.apache.commons.dbcp2.BasicDataSource#getConnection, then working with it, then calling Connection#close() when connection is not needed anymore.
Unfortunately, my pool grows infinitely and all connection are remain active.
How to put connection to idle, so pool could re-use it?
i have a question about connection pool and oracle database. if i set the min size of the connection pool to 5, does that means even when the app is idle, oracle database will still keep 5 sessions active? thanks!
Yes, it should keep connections even if app is idle. Good idea is to check if connection on pool is still alive. Wrappers like HikariCP/Commons DBCP handle such cases.
//edit
Connection pool wont start 5 connections on application start but it will initialize new connection if it will be needed. And of course pool can be set to shutdown connection after finishing operation on it.
Connection pool behavior doc link
I have a project in which I used HikariCP for JDBC connection pooling. And HikariCP works just great for my needs. It also logs the stats of the pool like below.
2014-12-03 10:16:08 DEBUG HikariPool:559 - Before cleanup pool stats loginPool (total=8, inUse=0, avail=8, waiting=0)
2014-12-03 10:16:08 DEBUG HikariPool:559 - After cleanup pool stats loginPool (total=7, inUse=1, avail=7, waiting=0)
Just for experimental purposes I closed all the MySQL connections for the configured database using MySQL Workbench. But, still I see HikariCP logging the stats like before though there are no actual connections to the database. When there was a request for connection it immediately established the connections(initial 8), so everything works great.
So, my question is how does these connections are managed or implemented? I think the reason why HikariCP logs stats, as if there were connections, is because it has valid in memory references to connections, which are actually non existent(with database).
Is my understanding correct?
When you close the connections using MySQL Workbench, you are closing them on the server end. On the JDBC (client) side, the previously established connections will remain in existence until the client code attempts to use them. At that point, they will be found to be "broken"; i.e. the client will get exceptions when it tries to use them.
The client-side JDBC Connection objects only get closed or recycled when they are returned to the connection pool by your Java application code.
The connection pool created 8 connections at startup. You say you disconnected them using the workbench. Most connection pools won't know the connection is disconnected until it gets used.
Your assumption is correct. You manually killed the connections but the pool has a handle to 8 sockets which it assumes are connected. Given time your connection pool may have checked the connections for validity and attempted to reconnect them. I can't speak for HikariCP but this is what modern connections pools do.
How can i stop database retry connection?using c3po i.e in my application i want to stop retry connection when i get database communication is fail
C3P0 documentation
Set up c3p0.properties in root of classpath
acquireRetryAttempts=1
As MJB says, setting c3p0's config parameter acquireRetryAttempts to 1 will cause clients to merely experience an Exception on a Connection acquisition failure rather than waiting and retrying.
If you wish for a c3p0 Connection pool to nevermore attempt to Connect to the database after a round of acquisition failures (with a "round" being defined by acquireRetryAttempts), set the config parameter breakAfterAcquireFailure to true. (By default this is false, c3p0 will try again to acquire Connections when new clients come calling.)
http://www.mchange.com/projects/c3p0/#acquireRetryAttempts
http://www.mchange.com/projects/c3p0/#breakAfterAcquireFailure