2012-06-04 8 views
11

Recentemente uno dei nostri server di produzione Tomcat non risponde perché i thread occupati di tomcat hanno raggiunto 200. Quando abbiamo eseguito il dump del thread prima di riavviarlo abbiamo ottenuto 100 thread in TIMED_WAITING stato come questi 3 fili:100 thread TIMED_WAITING in tomcat, provocando lo stallo del numero totale di thread incrociati 200

""http-bio-7007"-exec-241" daemon prio=10 tid=0x00002aaab107b000 nid=0x59df waiting on condition [0x0000000051239000] 
java.lang.Thread.State: TIMED_WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    - parking to wait for <0x0000000580d877d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025) 
    at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:424) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32) 
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) 
    at java.lang.Thread.run(Thread.java:662) 

""http-bio-7007"-exec-237" daemon prio=10 tid=0x00002aaab186e000 nid=0x596d waiting on condition [0x000000004d1f9000] 
java.lang.Thread.State: TIMED_WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    - parking to wait for <0x0000000580d877d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025) 
    at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:424) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32) 
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) 
    at java.lang.Thread.run(Thread.java:662) 

""http-bio-7007"-exec-236" daemon prio=10 tid=0x00002aaab1118000 nid=0x596c waiting on condition [0x000000004e50c000] 
java.lang.Thread.State: TIMED_WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    - parking to wait for <0x0000000580d877d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025) 
    at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:424) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86) 
    at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32) 
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) 
    at java.lang.Thread.run(Thread.java:662) 

Abbiamo pool di thread 4 dell'applicazione (ad esempio piscina-4-thread-20, ecc) anche che stanno avendo 20 filetti ogni modo non sono sicuro su cui il blocco coda questi 100 thread in attesa ? Stiamo usando il pool di connessioni c3P0 con l'ibernazione che non sembra essere la causa di questo.

Qualsiasi idea di cosa sia java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject?

+0

Hai provato a prendere un Heap Dump e a farlo scorrere attraverso [MAT] (http://www.eclipse.org/mat/) per vedere quali oggetti si stanno accumulando? –

+2

Al momento abbiamo lo stesso problema. Anche il riavvio di tomcat non ha aiutato. Dopo il riavvio, tutto ha funzionato di nuovo. STRANO! indagare ulteriormente e riferirò se trovo qualcosa di interessante. – Janning

+0

Non ha nulla a che fare con l'ibernazione in quanto abbiamo riscontrato questo problema stasera attraverso la nostra server farm completa e alcuni di loro sono solo server di immagini senza alcun hibernate o stack di database. – Janning

risposta

5

Questo problema è stato risolto quando abbiamo corretto il nostro codice che perdeva connessioni DB gestite da c3p0. C'erano pochi flussi nel nostro codice in cui non stavamo richiamando rollback() in modo specifico nel blocco catch prima di chiudere l'entity manager nel blocco finally, quindi in caso di eccezioni la connessione non tornava al pool e se la frequenza dell'eccezione era alta (più della dimensione del pool nell'intervallo di timeout), quindi tutti gli altri thread di processo si accumulerebbero per ottenere la connessione.

+0

Ho riscontrato lo stesso problema, puoi aiutarmi su come utilizzare la connessione? In modo che non possa avere perdite. – Mohanraj

4

Qualsiasi idea di cosa sia java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject?

Il ConditionObject viene utilizzato all'interno della coda per sincronizzare l'accesso alla coda da diversi thread.

È lo stacktrace standard, quando un thread del tuo executerpool è inattivo e in attesa di nuove attività.

Problemi correlati