Un día, no se pudo abrir la página web del servidor y con frecuencia se informó el siguiente error.
2007-3-18 1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
Grave: todos los subprocesos (150) están actualmente ocupados, esperando. Aumente maxThreads (150) o verifique el estado del servlet.
Aquí están las respuestas que creo que son correctas.
1. Creo que algunos de sus recursos no se han liberado y están bloqueados debido a un trabajo pendiente.
2. Problema del grupo de conexiones
3. Debería deberse al largo tiempo de procesamiento del hilo que responde a la solicitud en el lado del servidor
:
Solo había 2 personas usando el sitio web en ese momento, por lo que era imposible que 150 hilos simultáneos se conectaran. Entonces no debería ser un problema de base de datos.
A juzgar por los mensajes de error, debería deberse a un uso irrazonable del grupo de conexiones o al grupo de conexiones no está configurado en absoluto. La parte conectada a la base de datos se conecta utilizando la fuente de datos JDBC de Spring, de la siguiente manera:
<frijoles>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<!-- controlador para MySQL-->
<property name="driverClassName"><valor>org.gjt.mm.mysql.Driver</value></property>
<property name="url"><value>jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF8</value></property>
<nombre de propiedad="nombre de usuario"><valor>prueba</valor></propiedad>
<nombre de propiedad="contraseña"><valor>prueba</valor></propiedad>
</beans>
El problema debería ocurrir con DriverManagerDataSource de Spring, que es responsable de administrar estas conexiones.
La siguiente es una explicación de DriverManagerDataSource.
DriverManagerDataSource en Spring Framework
javax.sql Interfaz DataSource
Implementación de SmartDataSource que configura un controlador JDBC antiguo mediante
propiedades del bean y devuelve una nueva conexión cada vez.
Útil para entornos de prueba o independientes fuera de un contenedor J2EE.
como un bean DataSource en un ApplicationContext respectivo, o en conjunto con
un entorno JNDI simple que asume que las llamadas Connection.close() simplemente lo harán.
cierre la conexión, por lo que cualquier código de persistencia compatible con DataSource debería funcionar.
En un contenedor J2EE, se recomienda utilizar un JNDI DataSource proporcionado por el.
Un contenedor de este tipo se puede exportar como un bean DataSource en un
ApplicationContext a través de JndiObjectFactoryBean, para cambiar sin problemas desde y hacia
un bean DataSource local como esta clase.
Si necesita un grupo de conexiones "real" fuera de un contenedor J2EE, considere.
DBCP Jakarta Commons de Apache. Su BasicDataSource es un grupo de conexiones completo.
bean, que admite las mismas propiedades básicas que esta clase más configuraciones específicas.
Se puede utilizar como reemplazo de una instancia de esta clase simplemente cambiando
el nombre de clase de la definición de frijol para
"org.apache.commons.dbcp.BasicDataSource
--------------------------------------
".--------- ----------
Muchos proyectos de Yakarta admiten la interacción con una base de datos relacional.
Una nueva conexión para cada usuario puede llevar mucho tiempo (a menudo requiere varias
segundos de tiempo de reloj), para realizar una transacción de base de datos que podría
tomar milisegundos. Abrir una conexión por usuario puede ser inviable en un
Aplicación de Internet alojada públicamente donde se puede determinar el número de usuarios simultáneos.
ser muy grande, en consecuencia, los desarrolladores a menudo desean compartir un "grupo" de archivos abiertos.
conexiones entre todos los usuarios actuales de la aplicación. El número de usuarios.
realizar una solicitud en un momento dado suele ser un tiempo muy pequeño.
porcentaje del número total de usuarios activos, y durante el procesamiento de la solicitud es
la única vez que se requiere una conexión a la base de datos La aplicación en sí.
inicia sesión en el DBMS y maneja internamente cualquier problema de cuenta de usuario.
Ya hay varios grupos de conexiones de bases de datos disponibles, ambos dentro.
Productos de Yakarta y otros lugares. Este paquete de los Comunes brinda la oportunidad de
coordinar los esfuerzos necesarios para crear y mantener un sistema eficiente,
Paquete rico en funciones bajo la licencia ASF.
El paquete commons-dbcp se basa en el código del paquete commons-pool para proporcionar.
Los mecanismos de grupo de objetos subyacentes que utiliza.
Las aplicaciones pueden usar el componente commons-dbcp directamente o a través del existente.
interfaz de su contenedor/marco de soporte. Por ejemplo, Tomcat.
El contenedor de servlets presenta una fuente de datos DBCP como una fuente de datos JNDI James (Java.
Apache Mail Enterprise Server) ha integrado DBCP en el marco de Avalon.
La fuente de datos estilo Avalon se crea envolviendo la implementación de DBCP.
La lógica de agrupación de DBCP y la configuración que se encuentra en el código Excalibur de Avalon es
lo que se necesitaba para crear un DataSource integrado confiable
Después de leer la explicación, el hecho es que al establecer una conexión, DriverManagerDataSource crea una nueva conexión siempre que haya una conexión y no haya ningún grupo de conexiones. Sería mejor cambiar al siguiente grupo de conexiones de código abierto.
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="cerrar">
<nombre de propiedad="nombre de clase de controlador">
<valor>org.hsqldb.jdbcDriver</valor>
</propiedad>
<nombre de propiedad="url">
<valor>jdbc:hsqldb:hsql://localhost:9001</valor>
</propiedad>
<nombre de propiedad="nombre de usuario">
<valor>sa</valor>
</propiedad>
<nombre de propiedad="contraseña">
<valor></valor>
</propiedad>
</bean>
Se pasa la prueba y se elimina el problema. Si no hay un motor de búsqueda para encontrar la respuesta, el problema no se resolverá tan rápido.