2012-06-04 23 views
11

Niedawno jeden z naszych produkcyjnych serwerów Tomcat przestał odpowiadać, ponieważ intensywne wątki tomcata wystrzeliły do ​​200. Kiedy zrobiliśmy zrzut wątku przed ponownym uruchomieniem, otrzymaliśmy 100 wątków w TIMED_WAITING stan jak te 3 wątków:100 wątków TIMED_WAITING w tomcat, powodując ich zatrzymanie, ponieważ całkowita liczba wątków przekracza 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) 

Mamy baseny gwintem 4 aplikacji (np pool-4-thread-20 itp) także które mają 20 tematów każdy więc nie jestem pewien, w którym blokuje kolejce te 100 wątków oczekujących ? Używamy puli połączeń c3P0 ze stanem hibernacji, który nie wydaje się być tego przyczyną.

Każdy pomysł jaki java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject jest?

+0

Czy próbowałeś wziąć zrzut sterty i uruchomić go przez [MAT] (http://www.eclipse.org/mat/), aby zobaczyć, jakie obiekty się gromadzą? –

+2

W tej chwili mamy ten sam problem. Nawet ponowne uruchomienie tomcat nie pomogło. Po ponownym uruchomieniu ponownie wszystko działało. DZIWNE! nie zbadam dalej i zgłoszę, jeśli znajdę coś interesującego. – Janning

+0

Nie ma to nic wspólnego ze stanem hibernacji, ponieważ dzisiaj napotkaliśmy ten problem w całej naszej farmie serwerów, a niektóre z nich to tylko serwery obrazów bez stosu hibernacji lub bazy danych. – Janning

Odpowiedz

5

Zostało to naprawione, gdy naprawiliśmy nasz kod, który był nieszczelnym połączeniem DB zarządzanym przez c3p0. W naszym kodzie było niewiele przepływów, w których nie wywoływaliśmy rollback() w szczególności w bloku catch przed zamknięciem entity manager w końcu bloku, więc w przypadku wyjątków połączenie nie wróciło do puli i jeśli częstotliwość wyjątku jest wysoka (więcej niż rozmiar puli w przedziale limitu czasu), a następnie wszystkie inne wątki procesowe będą piętrzyć się, aby uzyskać połączenie.

+0

Otrzymuję ten sam problem, czy możesz mi pomóc, jak korzystać z połączenia? Aby nie doszło do wycieku. – Mohanraj

4

Każdy pomysł jaki java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject jest?

Obiekt ConditionObject służy w kolejce do synchronizowania dostępu do kolejki przez różne wątki.

Jest to standardowy ślad stosu, gdy wątek twojej przestrzeni roboczej jest bezczynny i czeka na nowe zadania.