C3P0 pozornego impasu wyjątek

wciąż otrzymuję ten wyjątek w moim dzienniku Tomcat:C3P0 pozornego impasu wyjątek

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)

Używam Hibernacja 3.6.2 i C3P0 0.9.1.2 z MySQL. Po kilku godzinach przeszukiwania Google ten wyjątek APPARENT DEADLOCK wydaje się zwykle kojarzony z przygotowanym buforowaniem instrukcji. To jest moja konfiguracja C3P0 w moim 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>

nie robię żadnych buforowanie oświadczenie ogóle. Wszelkie sugestie dotyczące tego, co tu jest nie tak, byłyby bardzo mile widziane.

Źródło

2013-08-07 corderazo00

Zadania, które są dealockingiem, są zadaniami pobierania połączenia. Oznacza to, że c3p0 próbuje uzyskać nowe połączenia z bazy danych, a próby pobrania połączenia trwają długo.

Pierwszą rzeczą, którą można zrobić, jest uaktualnienie do wersji 0.9.2.1, która ma znacznie udoskonalony sposób wykonywania rundy nabycia połączenia w sytuacjach, w których próby przejęcia czasami zawodzą.

Jeśli to nie rozwiąże problemu, musisz dowiedzieć się, dlaczego próby uzyskania połączenia przez C3p0 są zawieszone na długi czas: ani nie powiodło się, ani nie zawiodło w przypadku wyjątku.

Źródło

2013-08-07 10:41:31

Wygląda na to, że uaktualnienie mojego C3P0 do wersji 0.9.2.1! Dzięki @SteveWaldman za wskazówkę. – corderazo00

Wygląda na to, że to nie wystarczyło, APPARENT DEADLOCK powraca ... Czy istnieje sposób na monitorowanie działań c3p0 bliżej lub na niższym poziomie, aby zobaczyć, dlaczego dokładnie zwisa podczas próby zdobycia połączenia? – corderazo00

Czy usunięcie pamięci podręcznej serwera WWW (tomcat/work/Catalina) może mieć coś wspólnego z tym? Znalazłem wątki, w których ludzie twierdzą, że to rozwiązało ich problemy. – corderazo00

W moim szczególnym przypadku problem dotyczył konfiguracji serwera, na którym wdrożyłem moją aplikację.

Dopiero po wydrukowaniu ślad stosu mojego wniosku, że został powieszony, ponieważ sterownik Oracle czekał na bezpieczne liczb losowych generowane:

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)

Potem musiałem się nauczyć i zrozumieć trochę o hałasie entropijnym i mogłem sobie uświadomić, z niewielką pomocą moich znajomych z Unixu, że jeden z serwerów nie zainstalował pakietu generującego "hałas".

Jak wspomniano w następnym poście Pobiegłem kolejne polecenia: cat /proc/sys/kernel/random/entropy_avail 23 cat /proc/sys/kernel/random/poolsize 4096

Więc tam gdzie zbyt mało entropii dostępny do generowania bezpiecznego liczbę losową.

Po zainstalowaniu pakietu cat /proc/sys/kernel/random/entropy_avail 4096 Później nie miałem już pozornych zakleszczeń, moja aplikacja mogła uzyskać połączenia z bazą danych.

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

Źródło

2016-01-06 17:19:16

Mam podobny błąd podobny do tego wcześniej.

Może to być również spowodowane przez serwer bazy danych blokujący twoje IP. Upewnij się, że adresy IP Twoich serwerów nie są blokowane przez serwer bazy danych/dostawcę w chmurze.

W moim przypadku próbowałem wstawić dane do bazy danych w chmurze za pomocą wielowątkowości i działa tylko na serwerze lokalnym, ale nie na serwerze (w innej sieci).

Źródło

2016-09-02 22:12:33 simple

Odpowiedz

Powiązane problemy