Un jour, la page Web du serveur n'a pas pu être ouverte et l'erreur suivante a été fréquemment signalée.
2007-3-18 1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
Grave : tous les threads (150) sont actuellement occupés, en attente. Augmentez maxThreads (150) ou vérifiez l'état du servlet.
J'ai trouvé quelques réponses en ligne. Voici les réponses que je pense correctes :
1. Je pense que certaines de vos ressources n'ont pas été libérées et sont bloquées en raison d'un retard.
2. Problème de pool de connexions
3. Cela devrait être dû au long temps de traitement du thread répondant à la requête côté serveur
:
Il n'y avait que 2 personnes qui utilisaient le site Web à ce moment-là, il était donc impossible que 150 fils de discussion simultanés soient mis en ligne. Cela ne devrait donc pas être un problème de base de données.
À en juger par les invites d'erreur, cela devrait être dû à une utilisation déraisonnable du pool de connexions, ou le pool de connexions n'est pas défini du tout. La partie connectée à la base de données est connectée à l'aide de la source de données JDBC de Spring, comme suit :
<haricots>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<!-- pilote pour 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>
Le problème devrait survenir avec DriverManagerDataSource de Spring, qui est responsable de la gestion de ces connexions.
Ce qui suit est une explication de DriverManagerDataSource
DriverManagerDataSource dans Spring Framework
javax.sql Interface DataSource
Implémentation de SmartDataSource qui configure un ancien pilote JDBC via
propriétés du bean et renvoie une nouvelle connexion à chaque fois.
Utile pour les environnements de test ou autonomes en dehors d'un conteneur J2EE.
en tant que bean DataSource dans un ApplicationContext respectif, ou en conjonction avec
un environnement JNDI simple supposant que les appels Connection.close() seront simplement effectués.
fermez la connexion, donc tout code de persistance compatible DataSource devrait fonctionner
dans un conteneur J2EE, il est recommandé d'utiliser une source de données JNDI fournie par le.
Un tel conteneur DataSource peut être exporté en tant que bean DataSource dans un
ApplicationContext via JndiObjectFactoryBean, pour une commutation transparente vers et depuis
un bean DataSource local comme cette classe.
Si vous avez besoin d'un "vrai" pool de connexions en dehors d'un conteneur J2EE, envisagez-le.
Le DBCP Jakarta Commons d'Apache. Son BasicDataSource est un pool de connexions complet.
bean, prenant en charge les mêmes propriétés de base que cette classe ainsi que des paramètres spécifiques.
Il peut être utilisé en remplacement d'une instance de cette classe simplement en modifiant
le nom de classe de la définition du bean à
"org.apache.commons.dbcp.BasicDataSource
--------------------------------------
".--------- ----------
De nombreux projets Jakarta prennent en charge l'interaction avec une base de données relationnelle.
une nouvelle connexion pour chaque utilisateur peut prendre du temps (nécessitant souvent plusieurs
secondes de l'heure d'horloge), afin d'effectuer une transaction de base de données qui pourrait
prendre des millisecondes. L’ouverture d’une connexion par utilisateur peut être irréalisable dans un
application Internet hébergée publiquement où le nombre d'utilisateurs simultanés peut
être très vaste. En conséquence, les développeurs souhaitent souvent partager un « pool » d'espaces ouverts.
connexions entre tous les utilisateurs actuels de l’application. Le nombre d’utilisateurs.
exécuter réellement une requête à un moment donné est généralement un très petit
pourcentage du nombre total d'utilisateurs actifs, et pendant le traitement de la demande est
la seule fois où une connexion à la base de données est requise. L'application elle-même.
se connecte au SGBD et gère tous les problèmes de compte utilisateur en interne.
Plusieurs pools de connexions à la base de données sont déjà disponibles, tous deux au sein.
Produits de Jakarta et ailleurs. Ce paquet Commons offre l'opportunité de
coordonner les efforts requis pour créer et maintenir un système efficace,
package riche en fonctionnalités sous la licence ASF
Le package commons-dbcp s'appuie sur le code du package commons-pool pour fournir.
les mécanismes de pool d'objets sous-jacents qu'il utilise.
Les applications peuvent utiliser le composant commons-dbcp directement ou via le composant existant.
interface de leur conteneur/framework de support Par exemple le Tomcat.
Le conteneur de servlets présente une source de données DBCP en tant que source de données JNDI James (Java.
Apache Mail Enterprise Server) a intégré DBCP dans le framework Avalon.
La source de données de style Avalon est créée en encapsulant l'implémentation DBCP.
la logique de pooling de DBCP et la configuration trouvée dans le code excalibur d'Avalon sont
ce qui était nécessaire pour créer une DataSource intégrée fiable.
Après avoir lu l'explication, le fait est que lors de l'établissement d'une connexion, DriverManagerDataSource crée une nouvelle connexion tant qu'il y a une connexion, et qu'il n'y a pas de pool de connexions du tout. Il serait préférable de passer au pool de connexions open source suivant.
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<nom de la propriété="driverClassName">
<value>org.hsqldb.jdbcDriver</value>
</propriété>
<nom de la propriété="url">
<value>jdbc:hsqldb:hsql://localhost:9001</value>
</propriété>
<nom de propriété="nom d'utilisateur">
<valeur>sa</valeur>
</propriété>
<nom de la propriété="mot de passe">
<valeur></valeur>
</propriété>
</bean>
Le test est réussi et le problème est éliminé S'il n'y a pas de moteur de recherche pour trouver la réponse, le problème ne sera pas résolu aussi rapidement.