Troubleshooting the Tomcat data connection pool cannot be freed

In recent times, the company's Testing Center Reporting System (SMC) developers occasionally found me, saying that users are always unable to log in the situation. Some days ago, because of the JBoss cluster test work on hand, found that users can not log in, it is in Tomcat to reload this project, but only a temporary, because it will be a few hours later again can not log in the situation.

This morning, the development staff to find me, and asked me to help the problem to a radical cure, dragged too long users do not have to complain.

Simple analysis, each time reload can solve the situation cannot log in, it is natural to think that the session is not a problem? Then to the Tomcat manager interface looked down, found that there is no session sticky explosion situation.

Could have opened Jconsole to see, just think of the previous use of the Tomcat Detection tool: Probe, so directly from the other machine SCP a probe.war, dropped to the WebApps under the automatic deployment.

After deployment, open the probe Web management background to discover the number of real-time database connections for SMC projects is high, and only increase! The data pool size of this system is set to 200, this time is already 100 +, and has been only raised not down. Well, when the number of data connections reaches 200, the problem will definitely reappear.

So I told the problem to the little guy, and asked him to modify the connection pool release mechanism (this is used by the project parameters set separately). He said he tried, no use, ask me if I have a way.

My memory has been poor, and seldom to remember some parameter settings, ask me? Also I can only ask BD, GG ...

Finally, with the help of a powerful search engine, found the relevant parameter description, by reference to the modified successfully solved the problem!

Workaround for Tomcat connection pool not released:

Edit the connection pool profile for the project: Context.xml, refer to the following "database connection settings" parameter description, adjust the values according to the actual situation, especially Maxidle and maxactive. And remember to add removeabandoned=true related release parameters, we finally set the context.xml as shown below:

<resource name= "JDBC/SMC"
Type= "Javax.sql.DataSource"
Username= "User"
password= "Password"
Driverclassname= "Oracle.jdbc.driver.OracleDriver"
Maxidle= "50"
Maxwait= "2000"
Removeabandoned= "true"
removeabandonedtimeout= "180"
validationquery= "SELECT * from Dual"
Url= "JDBC:ORACLE:THIN:@192.168.7.98:1521:DW"
Maxactive= "/>"
1
2
3
4
5
6
7
8
9
10
11
12
<resource name= "JDBC/SMC"

Type= "Javax.sql.DataSource"

Username= "User"

password= "Password"

Driverclassname= "Oracle.jdbc.driver.OracleDriver"

Maxidle= "50"

Maxwait= "2000"

Removeabandoned= "true"

removeabandonedtimeout= "180"

validationquery= "SELECT * from Dual"

Url= "JDBC:ORACLE:THIN:@192.168.7.98:1521:DW"

Maxactive= "/>"

Database connection Settings Reference:

#数据库连接设置
Jdbc.driverclassname=oracle.jdbc.driver.oracledriver
Jdbcjdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:dbserver
Jdbc.username=user
Jdbc.password=pass

#<!--Initialize the connection--
datasource.initialsize=10

#<!--Maximum idle connection--
Datasource.maxidle=20

#<!--Minimum idle connection--
Datasource.minidle=5

#最大连接数量
Datasource.maxactive=50

#是否在自动回收超时连接的时候打印连接的超时错误
Datasource.logabandoned=true

#是否自动回收超时连接
Datasource.removeabandoned=true

#超时时间 (in seconds)
datasource.removeabandonedtimeout=180

#<!--Timeout Wait time in milliseconds-
datasource.maxwait=1000
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21st
22
23
24
25
26
27
28
29
#数据库连接设置

Jdbc.driverclassname=oracle.jdbc.driver.oracledriver

Jdbcjdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:dbserver

Jdbc.username=user

Jdbc.password=pass

#<!--Initialize the connection--

datasource.initialsize=10

#<!--Maximum idle connection--

Datasource.maxidle=20

#<!--Minimum idle connection--

Datasource.minidle=5

#最大连接数量

Datasource.maxactive=50

#是否在自动回收超时连接的时候打印连接的超时错误

Datasource.logabandoned=true

#是否自动回收超时连接

Datasource.removeabandoned=true

#超时时间 (in seconds)

datasource.removeabandonedtimeout=180

#<!--Timeout Wait time in milliseconds-

datasource.maxwait=1000

Attached to the author's original description:

When configuring the DBCP connection pool, the main difficult to understand is mainly: removeabandoned, logabandoned, Removeabandonedtimeout, maxwait four parameters, set the Rmoveabandoned=true Then in Getnumactive () near Getmaxactive (), the system will be invalid connection recovery, the connection is removeabandonedtimeout (default 300 seconds) Connection is not used after the number of seconds set in, the activation recycle mechanism appears to be getnumactive () =getmaxactive ()-2.

If "removeabandoned" is turned on, the connection may be reclaimed by the pool when it is considered compromised. This mechanism is triggered at (Getnumidle () < 2) and (Getnumactive () > Getmaxactive ()-3).

Example: When maxactive=20, active connection is 18, idle connection is 1 can trigger "removeabandoned". However, active connections are deleted only if they are not used for more than "Removeabandonedtimeout". The default is 300 seconds. Travels in ResultSet are not counted as being used.

Logabandoned=true, after the event, will be in the log to print out the recovery of connection error message, including where to use the connection but forget to shut down, when debugging is very useful.

Here private advice maxwait time not to set too long, maxwait if the setting is too long then the client will wait long before the reclamation event is fired.

Through the man's information, deepened my understanding of the connection pool parameters, thank you very much! Attach the original address: DBCP Connection Pool configuration parameter description and optimization, to show respect!

Troubleshooting the Tomcat data connection pool cannot be freed