Fehlende Verbindungen im Tomcat-jdbc-Verbindungspool

Werfen Sie einen Blick auf die Quelle von Verbindungspool.java Sie scheinen auf dieses Code-Snippet in borrowConnection() zu treffen Methode:

        //we didn't get a connection, lets see if we timed out
        if (con == null) {
            if ((System.currentTimeMillis() - now) >= maxWait) {
                throw new SQLException("[" + Thread.currentThread().getName()+"] " +
                    "Timeout: Pool empty. Unable to fetch a connection in " + (maxWait / 1000) +
                    " seconds, none available["+busy.size()+" in use].");
            } else {
                //no timeout, lets try again
                continue;
            }
        }

Demnach ist Ihre Verbindung also Null .

Der Wert von con wird auf der Zeile abgerufen:

PooledConnection con = idle.poll();

Wenn Sie den Code verfolgen, sehen Sie idle ist (abhängig von Ihrer Konfiguration, aber standardmäßig) FairBlockingQueue . Sie können die Implementierung auf Hinweise überprüfen.

Im Allgemeinen müssen Sie ResultSets, Statements und Connections immer schließen und verwendete Verbindungen sollten korrekt wieder in den Pool freigegeben werden. Wenn Sie dies nicht korrekt tun, können Verbindungen nie geschlossen werden => nie wieder für die Wiederverwendung verfügbar sein (Verbindungspool "Lecks" ).

Ich schlage vor, dass Sie den Zustand des Pools detailliert protokollieren und überwachen, um das Problem einzugrenzen.

Einige Richtlinien von Apache zum Verhindern von Lecks im Datenbankverbindungspool:

removeAbandoned="true"

abgebrochene Datenbankverbindungen werden entfernt und recycelt

removeAbandonedTimeout="60"

Legen Sie die Anzahl der Sekunden fest, die eine Datenbankverbindung im Leerlauf war, bevor sie als abgebrochen betrachtet wird

logAbandoned="true"

Protokollieren Sie eine Stacktrace des Codes, der die Datenbankverbindungsressourcen aufgegeben hat. Denken Sie daran, dass "das Protokollieren abgebrochener Verbindungen den Overhead für jede Verbindungsausleihe erhöht, da ein Stack-Trace generiert werden muss."

Ich denke immer noch, den maxWait leicht zu erhöhen Wert (1200, 1500, 1700 - einfach experimentieren, es wird keinen Unterschied in den Antwortzeiten aus Benutzersicht geben) wird die seltenen Fälle beseitigen, in denen Sie immer noch Probleme haben.