Соединение JDBC зависает

У одного из наших клиентов новая проблема: приложение зависает. Дамп потока показывает, что все потоки зависают на сетевом вводе-выводе в вызовах JDBC.

Мы / я никогда не видели этих зависаний «сетевого ввода-вывода». Обычно медленная машина с проблемами с БД имеет либо а) один или два длительных запроса, либо б) какой-то тип блокировки/взаимоблокировки. В любом из этих случаев потоки «зависают» на разных методах. Я никогда не видел, чтобы все 30+ потоков висели на сетевом вводе-выводе.

Ниже я включил выдержку из дампа потока. Все потоки HTTP зависают на одном вызове java.net.SocketInputStream.read.

Я разговаривал с их администратором баз данных и системным администратором. По их словам, в последнее время в окружающей среде «ничего не изменилось», что могло бы вызвать эту проблему.

среда БД

MSSQL 2005 64-разрядный пакет обновления 2 Драйвер: sqljdbc.jar: 1.0 809 102

Примечание: они используют более старый драйвер jdbc. Насколько я знаю, они пытались обновить драйвер с версии 1.0 до версии 1.2, но столкнулись с другой проблемой.

другие проблемы со средой

Они используют как сервер приложений, так и сервер базы данных в виртуальных машинах VMWare. Я не знаю, как эта настройка влияет на производительность сети.

Судя по всему это единственное приложение с такой проблемой. Я больше ничего не знаю об их сетевой архитектуре.

Вопросы * есть идеи по этой проблеме? * если это сеть, какие дальнейшие шаги для анализа?

Приложение А. Выдержка из дампа темы

Все HTTP-соединения висят на одном и том же методе:

"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)

person user72150    schedule 07.08.2009    source источник
comment
Я видел такие вещи, если соединение идет через глупый шлюз NAT.   -  person nos    schedule 08.08.2009


Ответы (2)


У нас были похожие проблемы, и мы проследили их до ошибочного обновления JDK (1.6.29).

Мы загрузили 1.6.27 (http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u27-oth-JPR), повторно установили JAVA_HOME окружающей среды, и мы вернулись на правильный путь.

person Steve Cutbush    schedule 02.11.2011
comment
Большое спасибо за точный ответ. У нас была точно такая же проблема, мы отслеживаем ее до пинга пула соединений JDBC в Glassfish, который зависает без каких-либо сообщений об ошибках. Вернитесь к 1.6.27, чтобы решить проблему. Спасибо - person Ido Ran; 21.11.2011
comment
Мы столкнулись с той же проблемой. Даунгрейд исправит это. - person Christian Kuetbach; 16.01.2012

Это изменения в JSSE в версии 1.6 u29. Изменение заключается в частичном исправлении CVE-2011-3389 и CVE-2011-3560.

Если не развертываются апплеты и не используется java web-start. Возможно, вы сможете просто использовать 1.6 u27 jsse.jar. Вы по-прежнему будете иметь уязвимость, но она позволит работать sqljdbc.jar и sqljdbc4.jar.

Другие варианты перехода на Java 7, sqljdbc4.jar, работают в этой среде.

Патч не является полным исправлением. Так что ожидайте больше изменений в будущих патчах.

person Jeremy Sanecki    schedule 03.11.2011