Perdita di memoria su Tomcat 7 con i driver Oracle JDBC 12c - impossibile interrompere il thread oracle.jdbc.driver

Question

Ho un'app Web distribuita su Tomcat 7.0.54 che utilizza un'origine dati per connettersi a un database Oracle 11g. L'origine dati è configurata in META-INF/context.xml e ho inserito ojdbc7.jar in <tomcat-install-dir>/lib. Io uso una ricerca JNDI per recuperare l'origine dati che immagazzino in un singleton in modo che ogni classe DAO possa usarla.

Tutto funziona come previsto, tuttavia quando ho annullare la distribuzione dell'applicazione (tramite Tomcat Manager app) che vedo nei log:

Oct 03, 2014 3:06:55 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/myapp] appears to have started a thread named [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] but has failed to stop it. This is very likely to create a memory leak. 
Oct 03, 2014 3:06:57 PM org.apache.catalina.startup.HostConfig undeploy 
INFO: Undeploying context [/myapp] 

Quando il debug posso vedere questa discussione viene creato non appena il database è accesso (tramite l'origine dati).

La mia origine dati di configurazione:

<Context antiResourceLocking="false"> 
    <Resource name="jdbc/myapp" auth="Container" 
     type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver" 
     maxActive="20" maxIdle="10" maxWait="-1" 
     username="myuser" password="mypass" 
     url="jdbc:oracle:thin:@myserver:1521:mysid" 
     removeAbandoned="true" removeAbandonedTimeout="10" logAbandoned="true" 
     validationQuery="SELECT 1 FROM DUAL" 
     testOnBorrow="true" testOnReturn="true" testWhileIdle="true" 
     timeBetweenEvictionRunsMillis="1800000" numTestsPerEvictionRun="3" 
     minEvictableIdleTimeMillis="1800000" 
    /> 
</Context> 

EDIT

Ulteriori indagini hanno rivelato che il problema si verifica se l'origine dati si accede durante l'applicazione (o servlet) inizializzazione.

In realtà, il thread problematico viene creato e quindi il problema esiste solo quando si utilizzano le versioni 12c dei driver JDBC di Oracle (ojdbc6.jar o ojdbc7.jar).

Se si ripristina l'utilizzo della versione 11.2.0.4 di ojdbc6.jar, il thread non viene mai creato e l'avviso di perdita di memoria non viene mai visualizzato.

Devo eseguire il downgrade del driver JDBC (come suggerito in https://stackoverflow.com/a/9177263/4105953)?

Answer 1

Ciò è normale, si verifica quando si distribuisce a caldo in Tomcat. Non ti causerà alcun problema normalmente in produzione perché generalmente non tieni gli aggiornamenti di distribuzione caldi in produzione, basta fermarti e riavviare il server.

Answer 2

Ho trovato una lunga discussione sull'argomento here. La conclusione è che crea una "perdita di memoria di dimensioni fisse", cioè successivi redeploys non aumenteranno la perdita di memoria.
Non ho accesso al supporto Oracle, ma l'ID bug menzionato nella discussione è 16841748 (maggio 2013, potrebbe essere risolto ora).

Una possibile soluzione è quella di utilizzare effettivamente l'origine dati una volta (ottenere connessione, eseguire una query fittizia, chiudere la connessione) quando Tomcat viene avviato tramite un servlet personalizzato configurato per "caricamento all'avvio" in tomcat/conf/web.xml. Questo dovrebbe avviare il/i thread/i del driver Oracle (vedere anche lo FAQ sui thread del driver) al di fuori dell'ambito del programma di caricamento classi della tua web-app, evitando così la "perdita di memoria di dimensione fissa".

Si noti che esiste un problema simile per il driver JDBC MySQL ma ha un decent solution. Tale soluzione potrebbe esistere per una versione recente del driver JDBC Oracle (non lo so).

Answer 3

Questo problema non si verifica solo con il driver JDBC Oracle (oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser).

Se una delle dipendenze di terze parti avvia un thread daemon per eseguire alcune attività, quindi durante l'arresto dei registri di Tomcat, viene visualizzato anche un messaggio di avviso.

Inoltre, questo problema esiste con le versioni di Tomcat 8.5.X.

Soluzione: Quello che ho trovato come soluzione è ottenere il Thread Group per il thread corrente e interromperlo. Si assicurerà che prima di spegnere Tomcat tutti i suoi thread daemon vengano uccisi.

codice seguente deve essere aggiunto al metodo "contextDestroyed" ThreadGroup threadGroup = Thread.currentThread(). GetThreadGroup(); threadGroup.interrupt();