Ontbrekende verbindingen in tomcat jdbc-verbindingspool

Een kijkje nemen in de bron van ConnectionPool.java je lijkt dit codefragment te raken in de borrowConnection() 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;
            }
        }

Dus volgens dit is je verbinding Null .

De waarde van con wordt opgehaald op de lijn:

PooledConnection con = idle.poll();

als je de code volgt, zie je idle is (afhankelijk van uw configuratie, maar standaard) FairBlockingQueue . U kunt de implementatie afrekenen voor hints.

Over het algemeen moet je ResultSets, Statements en Connections altijd sluiten en moeten gebruikte verbindingen correct worden teruggegeven aan de pool. Als u dit niet correct doet, kan dit ertoe leiden dat verbindingen nooit zijn gesloten => nooit meer beschikbaar zijn voor hergebruik (verbindingspool "lekt" ).

Ik stel voor dat je een gedetailleerde logboekregistratie maakt over de toestand van de pool en deze controleert om het probleem te isoleren.

Enkele richtlijnen van Apache om lekken van databaseverbindingspools te voorkomen:

removeAbandoned="true"

verlaten databaseverbindingen worden verwijderd en hergebruikt

removeAbandonedTimeout="60"

stel het aantal seconden in dat een databaseverbinding inactief is geweest voordat deze als verlaten wordt beschouwd

logAbandoned="true"

log een stacktracering van de code die de databaseverbindingsbronnen heeft verlaten. Houd er rekening mee dat "het loggen van verlaten Connections extra overhead toevoegt voor elke Connection-lening omdat er een stacktracering moet worden gegenereerd."

Ik denk nog steeds dat de maxWait . lichtjes wordt verhoogd waarde (1200, 1500, 1700 - experimenteer gewoon, er zal geen verschil zijn in de reactietijden vanuit gebruikersperspectief) zal die zeldzame gevallen wissen waarin u nog steeds problemen ondervindt.