One day, the web page on the server could not be opened, and the following error was frequently reported.
2007-3-18 1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
Severe: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status.
I found some answers online. Here are the answers I think are correct:
1. I think some of your resources have not been released and are stuck due to backlog.
2. Connection pool problem
3. It should be caused by the long processing time of the thread responding to the request on the server side
:
There were only 2 people using the website at that time, so it was impossible for 150 concurrent threads to come online. So it shouldn't be a database problem.
Judging from the error prompts, it should be caused by unreasonable use of the connection pool, or the connection pool is not set at all. The part connected to the database is connected using Spring's data source JDBC, as follows:
<beans>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<!-- driver for MySQL-->
<property name="driverClassName"><value>org.gjt.mm.mysql.Driver</value></property>
<property name="url"><value>jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF8</value></property>
<property name="username"><value>test</value></property>
<property name="password"><value>test</value></property>
</beans>
The problem should occur with Spring's DriverManagerDataSource, which is responsible for managing these connections.
The following is an explanation of DriverManagerDataSource
DriverManagerDataSource in Spring Framework
javax.sql Interface DataSource
Implementation of SmartDataSource that configures a plain old JDBC Driver via
bean properties, and returns a new Connection every time.
Useful for test or standalone environments outside of a J2EE container, either
as a DataSource bean in a respective ApplicationContext, or in conjunction with
a simple JNDI environment. Pool-assuming Connection.close() calls will simply
close the connection, so any DataSource-aware persistence code should work.
In a J2EE container, it is recommended to use a JNDI DataSource provided by the
container. Such a DataSource can be exported as a DataSource bean in an
ApplicationContext via JndiObjectFactoryBean, for seamless switching to and from
a local DataSource bean like this class.
If you need a "real" connection pool outside of a J2EE container, consider
Apache's Jakarta Commons DBCP. Its BasicDataSource is a full connection pool
bean, supporting the same basic properties as this class plus specific settings.
It can be used as a replacement for an instance of this class just by changing
the class name of the bean definition to
"org.apache.commons.dbcp.BasicDataSource".
----------------------------------------------- ----------
Many Jakarta projects support interaction with a relational database. Creating a
new connection for each user can be time consuming (often requiring multiple
seconds of clock time), in order to perform a database transaction that might
take milliseconds. Opening a connection per user can be unfeasible in a
publicly-hosted Internet application where the number of simultaneous users can
be very large. Accordingly, developers often wish to share a "pool" of open
connections between all of the application's current users. The number of users
actually performing a request at any given time is usually a very small
percentage of the total number of active users, and during request processing is
the only time that a database connection is required. The application itself
logs into the DBMS, and handles any user account issues internally.
There are several Database Connection Pools already available, both within
Jakarta products and elsewhere. This Commons package provides an opportunity to
coordinate the efforts required to create and maintain an efficient,
feature-rich package under the ASF license.
The commons-dbcp package relies on code in the commons-pool package to provide
the underlying object pool mechanisms that it utilizes.
Applications can use the commons-dbcp component directly or through the existing
interface of their container / supporting framework. For example the Tomcat
servlet container presents a DBCP DataSource as a JNDI Datasource. James (Java
Apache Mail Enterprise Server) has integrated DBCP into the Avalon framework. A
Avalon-style datasource is created by wrapping the DBCP implementation. The
pooling logic of DBCP and the configuration found in Avalon's excalibur code is
what was needed to create an integrated reliable DataSource.
After reading the explanation, the fact is that when establishing a connection, DriverManagerDataSource creates a new connection as long as there is a connection, and there is no connection pool at all. It would be better to switch to the following open source connection pool.
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName">
<value>org.hsqldb.jdbcDriver</value>
</property>
<property name="url">
<value>jdbc:hsqldb:hsql://localhost:9001</value>
</property>
<property name="username">
<value>sa</value>
</property>
<property name="password">
<value></value>
</property>
</bean>
The test is passed and the problem is eliminated. If there is no search engine to find the answer, the problem will not be solved so quickly.