Sql Server JDBC Connection Reset Ошибка: только на Amazon EC2

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

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

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

Проблема В этой облачной настройке мы получаем прерывистое "соединение reset путем одноранговых ошибок" между базой данных и драйвером 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. Это заставило меня задуматься, поможет ли виртуальное частное облако.

заблаговременно

будет

Ответ 1

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

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

Вы можете попытаться вырвать трассировку Wireshark/PCAP, найти, когда это произойдет, и отправить результаты как Amazon, так и Microsoft, чтобы узнать, могут ли они вызывать причину этого.
Вы можете попробовать это с помощью определенных тестовых жгутов, чтобы изолировать проблему (тесты JMeter для получения concurrency вверх), отскок сетевого подключения, просмотр восстановления и т.д.
Вы можете попробовать альтернативные версии SQL Server, чтобы исключить ошибку драйвера SQL Server/JDBC, которая с тех пор была исправлена.
Если DNS используется в строках подключения, он может использовать IP-адреса для проверки проблем nslookup.

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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