Ошибка сброса соединения JDBC сервера SQL: только на Amazon EC2

Question

Контекст: Облако

У нас есть веб-приложение на основе Java, которое мы обычно размещаем на наших собственных серверах.Недавно мы использовали облако Amazon Web Services (AWS EC2) для размещения экземпляра.

Эта «настройка облака» соответствует нашей типичной настройке «на месте»: один сервер для сервера приложений, другой сервер для сервера базы данных.(Несколько серверов приложений указывают на один и тот же сервер базы данных)

Проблема В этой облачной настройке мы получаем прерывистый «сброс соединения по одноранговым ошибкам» между базой данных и драйвером jdbc, где на(казалось бы) случайные интервалы и в случайных точках в кодовой базе соединение с базой данных завершается неудачно.

Вот несколько отрывков ошибок для журнала

Пример трассировки стека 1:

at com.participate.pe.genericdisplay.client.taglib.GenDisplayViewTag.doStartTag(GenDisplayViewTag.java:77)
    ... 75 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
    at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.getMetaData(SQLServerConnection.java:1734)
    at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:354)

Пример трассировки стека 2

    at java.lang.Thread.run(Thread.java:619)
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1355)
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1532)
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3274)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4437)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1457)
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1416)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1462)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1610)
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429)

Техническая среда

• Jboss 4.2.2.GA (Jboss-Web 2.0 / Tomcat 6)
• MSSQL 2005 2.0 JDBC-драйвер

Некоторые баллы

• У нас есть никогда не видел эту проблему в нашей собственной среде (то есть в собственных центрах обработки данных), в которой приложение работало в течение нескольких лет
• Это привело меня к выводу, что «в сетевой среде Amazon происходит нечто странное».Я могу ошибаться / что-то упустить / т.д.
• Эта проблема возникает только с нашим приложением.У нас есть другие приложения java и php, у которых не было этой проблемы.Другое java-приложение использует другой драйвер jdbc (jtds, afaik)
• Это не похоже на простое время ожидания соединения

Вопросы

- Кто-нибудь видел это раньше?-Если это «известная проблема» в EC2, можем ли мы настроить способ ее решения (т. Е. Убедиться, что все находится в собственной подсети или виртуальном частном облаке (vpc)?) -Все настройки драйвера jdbc позволяют обойти эту проблему?

** Обновление ** Я увеличил и увеличил награду за этот вопрос.

Дополнительная информация: два виртуальных сервера (база данных и сервер приложений) находились в разных подсетях - т.е. однапрыжок между двумя серверами.

В не облачной среде мы имеем «нулевой скачок» между двумя серверами.

Наши администраторы хостинга сказали, что у нас нет контроля над подсетями наших экземпляров EC2Это заставило меня задуматься, поможет ли виртуальное частное облако.

заранее спасибо

будет

Answer 1

Не уверен, связано ли это или нет.Мы испытали нечто подобное с приложением, которое мы работали в среде EC2.Тот же симптом, что соединение с базой данных будет прерывисто прерываться.Мы использовали драйвер MSSQL 1.2.Кроме того, мы увидим ошибки обычно после задержки или простоя с подключением.Наше предположение (никогда не было доказано) заключалось в том, что что-то на сетевом уровне закрывало соединение, а клиент не обнаруживал его, поэтому оно устарело.

Мы смогли обойти это, потому что мы использовали общениепулы, и имел пул воссоздать соединение при сбое.В итоге мы переместили приложение из EC2 и больше не видели проблемы.

Answer 2

Я видел эту проблему как в среде EC2, так и в среде Windows Azure. Я думаю, что логика повторных подключений должна быть стандартной частью вашего проекта при работе в распределенной вычислительной среде.

Эта статья предназначена для SQL Azure, но я думаю, что она в равной степени относится к EC2 и всем драйверам.

Answer 3

Просто предостережение о возможностях DBCP / пула соединений usind для смягчения этой проблемы - чем больше вы включаете testOnBorrow и другие функции, тем больше вы можете вносить задержки или другие изменения производительности в системе.Я не знаю, по-прежнему ли это делает DBCP или нет, но несколько лет назад он генерировал бы реальные тестовые запросы для проверки соединения - полный стек, ответы базы данных - не только на сетевом уровне.Приведенная выше ссылка от Брайана возвращает ужасные воспоминания начала 2000-х годов об окружающей логике повторных попыток управления соединениями JDBC.

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

• Вы можете попытатьсябросить трассировку Wireshark / PCAP, найти, когда это произойдет, и отправить результаты в Amazon и Microsoft, чтобы выяснить, могут ли они вызвать root

• Вы можете попробовать описанное выше с определенным тестомсредства для выявления проблемы (тесты JMeter для обеспечения параллелизма), отказов сетевого подключения, отслеживания восстановления и т. д.

• Вы можете попробовать альтернативные версии SQL Server, чтобы сделать скидку на SQL Server /.Исправлена ​​ошибка драйвера JDBC.

• Если DNS используется в строках соединения, может использовать IP-адреса для проверки проблем nslookup

IЯ не являюсь экспертом по SQL Server, но другой путь для исследований может быть в рамках домена связанных продуктов - например, посмотреть, сталкивался ли кто-либо с подобными проблемами с TFS / Sharepoint (например, такими как http://nickhoggard.wordpress.com/2009/12/07/further-experiences-with-tfs-2010-beta-2-on-amazon-ec2/)

Answer 4

Я также могу подтвердить, что это происходит, и ускорит расследование с более низким приоритетом, поскольку оно не критично для производства.
Наши производственные серверы находятся в нашем дата-центре. Мы используем ноутбуки разработчиков для запуска наших приложений. Ни один из них не получает эту проблему, как только мы настроили тайм-ауты пула соединений c3p0 и период тестирования (см. Статью: http://www.codefin.net/2007/05/hibernate-and-mysql-connection-timeouts.html).

Однако у нас есть промежуточный сервер разработки, который находится в EC2, и это действительно происходит там. Если я найду что-то, что, кажется, работает, я перезвоню. Также я использую mysql. Я вижу, что вы используете MS SQL Server, поэтому он распространяется на поставщиков баз данных.