Eines Tages konnte die Webseite auf dem Server nicht geöffnet werden und der folgende Fehler wurde häufig gemeldet.
2007-3-18 1:08:26 org.apache.tomcat.util.threads.ThreadPool logFull
Schwerwiegend: Alle Threads (150) sind derzeit beschäftigt und warten auf max. Threads (150).
Ich habe online einige Antworten gefunden.
1. Ich denke, einige Ihrer Ressourcen wurden nicht freigegeben und stecken aufgrund von Rückständen fest.
2. Verbindungspoolproblem
3. Es sollte an der langen Verarbeitungszeit des Threads liegen, der auf die Anforderung auf der Serverseite antwortet
:
Da die Website zu diesem Zeitpunkt nur von zwei Personen genutzt wurde, war es unmöglich, dass 150 gleichzeitige Threads online gingen. Es sollte also kein Datenbankproblem sein.
Den Fehleraufforderungen nach zu urteilen, sollte dies an einer unangemessenen Nutzung des Verbindungspools liegen oder der Verbindungspool ist überhaupt nicht festgelegt. Der mit der Datenbank verbundene Teil wird wie folgt über die Datenquelle JDBC von Spring verbunden:
<Bohnen>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<!-- Treiber für 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>
Das Problem sollte bei Springs DriverManagerDataSource auftreten, das für die Verwaltung dieser Verbindungen verantwortlich ist.
Im Folgenden finden Sie eine Erläuterung von DriverManagerDataSource
DriverManagerDataSource im Spring Framework
javax.sql Interface DataSource
Implementierung von SmartDataSource, das einen einfachen alten JDBC-Treiber über konfiguriert
Bean-Eigenschaften und gibt jedes Mal eine neue Verbindung zurück.
Nützlich auch für Test- oder Standalone-Umgebungen außerhalb eines J2EE-Containers
als DataSource-Bean in einem entsprechenden ApplicationContext oder in Verbindung mit
Eine einfache JNDI-Umgebung unter der Annahme, dass Connection.close()-Aufrufe einfach erfolgen
Schließen Sie die Verbindung, sodass jeder DataSource-fähige Persistenzcode funktionieren sollte.
In einem J2EE-Container wird empfohlen, eine von bereitgestellte JNDI-DataSource zu verwenden
Eine solche DataSource kann als DataSource-Bean in einen exportiert werden
ApplicationContext über JndiObjectFactoryBean, für nahtloses Wechseln zu und von
eine lokale DataSource-Bean wie diese Klasse.
Wenn Sie einen „echten“ Verbindungspool außerhalb eines J2EE-Containers benötigen, sollten Sie darüber nachdenken
Apaches Jakarta Commons DBCP ist ein vollständiger Verbindungspool
Bean, die dieselben grundlegenden Eigenschaften wie diese Klasse sowie spezifische Einstellungen unterstützt.
Es kann durch einfaches Ändern als Ersatz für eine Instanz dieser Klasse verwendet werden
Der Klassenname der Bean-Definition
„org.apache.commons.dbcp.BasicDataSource“
------------------------------------- --------- ----------
Viele Jakarta-Projekte unterstützen die Interaktion mit einer relationalen Datenbank
Das Erstellen einer neuen Verbindung für jeden Benutzer kann zeitaufwändig sein (oft sind mehrere erforderlich).
Sekunden Uhrzeit), um eine Datenbanktransaktion durchzuführen, die ggf
Das Öffnen einer Verbindung pro Benutzer kann in einem Jahr unmöglich sein
Öffentlich gehostete Internetanwendung, bei der die Anzahl gleichzeitiger Benutzer möglich ist
Dementsprechend möchten Entwickler oft einen „Pool“ offener Ressourcen teilen
Verbindungen zwischen allen aktuellen Benutzern der Anwendung
Die tatsächliche Ausführung einer Anfrage zu einem bestimmten Zeitpunkt ist normalerweise sehr gering
Prozentsatz der Gesamtzahl der aktiven Benutzer und während der Anfrageverarbeitung beträgt
Das einzige Mal, dass eine Datenbankverbindung erforderlich ist
meldet sich beim DBMS an und kümmert sich intern um alle Benutzerkontoprobleme.
Es sind bereits mehrere Datenbankverbindungspools verfügbar
Jakarta-Produkte und anderswo. Dieses Commons-Paket bietet die Möglichkeit dazu
Koordinieren Sie die erforderlichen Anstrengungen zur Schaffung und Aufrechterhaltung eines effizienten,
Funktionsreiches Paket unter der ASF-Lizenz.
Das Paket commons-dbcp basiert auf dem Code im Paket commons-pool
Die zugrunde liegenden Objektpoolmechanismen, die es nutzt,
können die commons-dbcp-Komponente direkt oder über die vorhandene verwenden
Schnittstelle ihres Containers/unterstützenden Frameworks. Zum Beispiel der Tomcat
Der Servlet-Container stellt eine DBCP-Datenquelle als JNDI-James-Datenquelle dar
Apache Mail Enterprise Server) hat DBCP in das Avalon-Framework A integriert
Eine Datenquelle im Avalon-Stil wird durch Umschließen der DBCP-Implementierung erstellt
Die Pooling-Logik von DBCP und die Konfiguration im Excalibur-Code von Avalon sind
Was erforderlich war, um eine integrierte zuverlässige DataSource zu erstellen.
Nach dem Lesen der Erklärung stellt DriverManagerDataSource fest, dass beim Herstellen einer Verbindung eine neue Verbindung erstellt wird, solange eine Verbindung besteht, und es überhaupt keinen Verbindungspool gibt. Es wäre besser, zum folgenden Open-Source-Verbindungspool zu wechseln.
<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">
<Wert></Wert>
</property>
</bean>
Der Test ist bestanden und das Problem ist behoben. Wenn es keine Suchmaschine gibt, die die Antwort findet, wird das Problem nicht so schnell gelöst.