2009-08-07 10 views
5

Jeden z naszych klientów ma nowy problem: aplikacja zatrzymuje się. Zrzut wątku pokazuje, że wszystkie wątki są zawieszone w sieciowym we/wy w wywołaniach JDBC.Połączenie JDBC wiszące

My/ja nigdy nie widziałem tych "sieci IO" wisi. Zwykle problemy z powolną maszyną w/DB mają albo a) jedno lub dwa długo działające zapytania, albo b) jakiś rodzaj blokady/zakleszczenia. W każdym z tych przypadków wątki "zawieszają się" na różnych metodach. Nigdy nie widziałem wszystkich 30 wątków wiszących w sieci IO.

Poniżej zamieściłem wycinek ze zrzutu wątku. Wszystkie wątki HTTP są zawieszone na tym samym wywołaniu java.net.SocketInputStream.read.

Rozmawiałem z ich dba i sysadmin. Według nich "nic się nie zmieniło" w środowisku, które ostatnio spowodowałoby ten problem.

środowisko db

MSSQL 2005 64-bit Service Pack 2 Kierowca: sqljdbc.jar: 1,0 809 102

Uwaga: są one uruchomione starszą sterownika JDBC. AFAIK próbowali aktualizacji z wersji 1.0 do sterownika 1.2, ale mieli też inny problem.

inne środowisko wydaje

Uciekają zarówno serwera aplikacji i serwera bazy danych w VMWare VM. Nie wiem, jak ta konfiguracja wpływa na wydajność sieci.

Podobno jest to jedyna aplikacja z tym problemem. Nie wiem nic więcej o ich architekturze sieci.

Pytania * Jakiekolwiek informacje na temat tego problemu? * jeśli jest to sieć, kolejne kroki do analizy?

Dodatek A: Wyciąg z nici zrzucić

Wszystkie połączenia HTTP wiszą na tej samej metody:

 
"TP-Processor31" daemon prio=5 tid=0x04085b78 nid=0x970 runnable [0x0764d000..0x0764fd6c] 
    at java.net.SocketInputStream.socketRead0(Native Method) 
    at java.net.SocketInputStream.read(SocketInputStream.java:129) 
    at com.microsoft.sqlserver.jdbc.DBComms.receive(Unknown Source) 
    at com.microsoft.sqlserver.jdbc.IOBuffer.sendCommand(Unknown Source) 
    - locked (a com.microsoft.sqlserver.jdbc.DBComms) 
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.sendExecute(Unknown Source) 
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteQuery(Unknown Source) 
+0

Widziałem takie rzeczy, jeśli połączenie przechodzi przez głupią bramę NAT – nos

Odpowiedz

8

mieliśmy podobne problemy, i wywodzi je z powrotem do wózka JDK aktualizacji (1.6.29).

Pobrano wersję 1.6.27 (http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u27-oth-JPR), ponownie - ustaw środowisko JAVA_HOME i wróciliśmy na właściwe tory.

+2

Dziękuję bardzo za dokładną odpowiedź. Mieliśmy dokładnie ten sam problem, śledzimy go do pingowania puli połączeń JDBC w Glassfish, która zawiesza się bez żadnego komunikatu o błędzie. Wróć do wersji 1.6.27, aby rozwiązać problem. Dziękujemy –

+0

Znaleźliśmy ten sam problem. Downgrade to naprawi. –

2

To zmiany w JSSE w wersji 1.6 u29. Zmiana ma na celu częściowe poprawienie CVE-2011-3389 i CVE-2011-3560.

Jeśli nie są wdrażanie aplety i przy użyciu java web-start. Być może będziesz mógł po prostu użyć pliku jsse.jar 1.6 u27. Nadal będziesz narażony na tę usterkę, ale pozwoli to na działanie sqljdbc.jar i sqljdbc4.jar.

Inne opcje migracji do Java 7, sqljdbc4.jar działa w tym środowisku.

Poprawka nie jest kompletna. Więc oczekuj więcej zmian w przyszłych łatach.

Powiązane problemy