c3p0 apparente eccezione DEADLOCK

continuo a ricevere questa eccezione nel mio ceppo Tomcat:c3p0 apparente eccezione DEADLOCK

com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run 
WARNING: com[email protected]76b28200 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks! 
com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run 
WARNING: com[email protected]76b28200 -- APPARENT DEADLOCK!!! Complete Status: 
    Managed Threads: 3 
    Active Threads: 3 
    Active Tasks: 
     [email protected]18 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1) 
     [email protected]e4 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0) 
     [email protected]d8 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2) 
    Pending Tasks: 
     [email protected]53 
     [email protected]24 
Pool thread stack traces: 
    Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1,5,main] 
     java.lang.Thread.sleep(Native Method) 
     com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1805) 
     com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) 
    Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0,5,main] 
     java.lang.Thread.sleep(Native Method) 
     com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1805) 
     com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) 
    Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2,5,main] 
     java.lang.Thread.sleep(Native Method) 
     com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1805) 
     com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

Sto usando Hibernate 3.6.2 e 0.9.1.2 C3P0 con MySQL. Dopo un paio d'ore di ricerche su Google, questa eccezione DEADLOCK APPARENT sembra essere in genere associata alla cache delle istruzioni preparate. Questa è la mia configurazione C3P0 nel mio hibernate.cfg.xml:

<propertyname="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property> 
<property name="hibernate.c3p0.acquire_increment">5</property> 
<property name="hibernate.c3p0.min_size">5</property> 
<property name="hibernate.c3p0.max_size">60</property> 
<property name="hibernate.c3p0.idle_test_period">120</property> 
<property name="hibernate.c3p0.timeout">180</property>    
<property name="hibernate.c3p0.max_statements">0</property>

non sto facendo alcun caching dichiarazione di sorta. Qualsiasi suggerimento su ciò che è sbagliato qui sarebbe molto apprezzato.

fonte

2013-08-07 corderazo00

Le attività che sono dealocking sono attività di acquisizione connessioni. Cioè, c3p0 sta cercando di acquisire nuove connessioni dal tuo database e quei tentativi di acquisizione di Connection richiedono molto tempo.

La prima cosa che farei è l'aggiornamento alla 0.9.2.1, che ha un mezzo molto migliorato per eseguire un giro di acquisizioni di Connection in situazioni in cui i tentativi di acquisizione a volte falliscono.

Se ciò non risolve il problema, è necessario capire perché i tentativi di acquisizione di una connessione di c3p0 sono sospesi per lunghi periodi di tempo: né riusciti né fallendo con un'eccezione.

fonte

2013-08-07 10:41:31

Sembra che l'aggiornamento del mio c3p0 alla versione 0.9.2.1 abbia funzionato! Grazie a @SteveWaldman per il suggerimento. – corderazo00

Apparentemente non ha funzionato, APPARENT DEADLOCK è tornato ... C'è un modo per monitorare le attività di c3p0 più vicino o ad un livello più basso per capire perché è esattamente sospeso quando si tenta di acquisire una connessione? – corderazo00

L'eliminazione della cache del server web (tomcat/work/Catalina) può avere qualcosa a che fare con questo? Ho trovato alcuni thread in cui la gente afferma che questo ha risolto i loro problemi. ridistribuire caldo – corderazo00

Nel mio caso particolare il problema riguardava la configurazione del server in cui distribuivo la mia applicazione.

fu solo dopo stampando la traccia dello stack della mia candidatura che è stato appeso, perché il driver Oracle era in attesa di un numero casuale sicuro viene generato:

Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2,5,main] 
    java.io.FileInputStream.readBytes(Native Method) 
    java.io.FileInputStream.read(FileInputStream.java:255) 
    sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539) 
    sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144) 
    sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:203) 
    sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221) 
    java.security.SecureRandom.nextBytes(SecureRandom.java:468) 
    oracle.security.o5logon.O5Logon.a(Unknown Source) 
    oracle.security.o5logon.O5Logon.(Unknown Source) 
    oracle.jdbc.driver.T4CTTIoauthenticate.(T4CTTIoauthenticate.java:582) 
    oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:401) 
    oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:553) 
    oracle.jdbc.driver.T4CConnection.(T4CConnection.java:254) 
    oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) 
    oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528) 
    com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134) 
    com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182) 
    com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171) 
    com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137) 
    com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014) 
    com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32) 
    com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810) 
    com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

Poi ho dovuto imparare e capire un po ' sul rumore di entropia e potrebbe realizzare, con un piccolo aiuto dai miei amici Unix, che uno dei server non aveva installato un pacchetto che genera il "rumore".

Come accennato nel seguente post mi sono imbattuto nei prossimi comandi: cat /proc/sys/kernel/random/entropy_avail 23 cat /proc/sys/kernel/random/poolsize 4096

Così là dove troppo pochi entropia a disposizione per generare un numero casuale sicuro.

Dopo aver installato il pacchetto cat /proc/sys/kernel/random/entropy_avail 4096 Successivamente non ho avuto più deadlock apparenti, la mia applicazione potrebbe ottenere connessioni al DB.

http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty/

fonte

2016-01-06 17:19:16

Got un errore simile come questo prima.

Potrebbe anche essere causato dal server di database che blocca il tuo IP. Assicurati che l'IP del tuo server non sia bloccato dal server database/provider cloud.

Nel mio caso, stavo cercando di inserire dati nel database nel cloud con il multithreading, e funziona solo sul locale, ma non su un server (su una rete diversa).

fonte

2016-09-02 22:12:33 simple

c3p0 apparente eccezione DEADLOCK

risposta

Problemi correlati