Some time ago, I wrote a Demo project. The client connects through the network and accesses a background implemented by netty to obtain data.
Although the work tasks of background netty also complete the corresponding task processing through the thread pool, but occasionally when the client reads data, the reading thread gets stuck and cannot read the data, and it only appears occasionally. I have tried a lot. Second, every time I observed it, it did not reproduce, and even stress tests did not occur, and there was no task problem in local Debug. By adding logs at each step, it was found that the task was added to the thread pool and was not executed in the end, and the thread pool was full. If it is dropped, whether there is a deadlock at a certain step in Huai Ning, and then carefully check the code for a few rounds, there is no possibility of a deadlock.
After many problems, I found a rule: "When there is a problem, you don't have access to the background for a long time, and then it is more likely to appear when you visit it than usual."
Based on the above rules, it may be that a certain resource in the background is released or expired due to expiration, and the only resource used is the database, the C3P0 database connection pool configured by spring. View configuration files:
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="com.mysql.jdbc.Driver"/>
<property name="jdbcUrl" value="jdbc:mysql://xx.xx.xx.xx/xxx"/>
<property name="user" value="xxx"/>
<property name="password" value="xxx"/>
<property name="minPoolSize" value="1"/>
<property name="maxPoolSize" value="20"/>
<property name="checkoutTimeout" value="10000"/>
<property name="maxStatementsPerConnection" value="50"/>
<property name="testConnectionOnCheckout" value="true"/>
</bean>
In the configuration, the connection checkout is checked, and the timeout is not long. Logically, there should be no problem.
Carefully read the explanation of this parameter, testConnectionOnCheckout is to check the data by querying the data once or calling isValid() after JDBC4 and C3P00.9.5 . Inquire.
Then I also found that the connection that mysql has not used for a long time will be stuck, that is, the idle state. I think that C++ access to Mysql also has this problem before. Finally, I wrote a thread myself, and I do it every once in a while. A simple query to solve, in fact, my situation is very stuck at the time of checkout, but not the connection timeout, nor the checkout supermarket, and then look at the parameter configuration of C3P0, and there is an idleConnectionTestPeriod, this is Regularly "activate" the idle connection, and after adding it, everything is fine, and the problem has never appeared again. Another parameter is also recommended to be added and used together. The final configuration is as follows:
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> <property name="driverClass" value="com.mysql.jdbc.Driver"/><!-- 203.195.235.154 119.29.178.28--> <property name="jdbcUrl" value="jdbc:mysql://xx.xx.xx.xx/xxx"/> <property name="user" value="xxxxx"/> <property name="password" value="xxxx"/> <property name="minPoolSize" value="1"/> <property name="maxPoolSize" value="20"/> <property name="checkoutTimeout" value="10000"/> <property name="maxStatementsPerConnection" value="50"/> <property name="automaticTestTable" value="pooltest"/> <property name="testConnectionOnCheckout" value="true"/> <property name="testConnectionOnCheckin" value="true"/> <property name="idleConnectionTestPeriod" value="60"/> </bean>
automaticTestTable, which is optional, indicates that when the connection pool is testing, a table name accessed will be automatically created, and statements such as select 1 will be executed. After the table is created, there is no need to manually modify it.
Write it down as a reminder.