#tomcat #jdbc #proxy #snowflake-cloud-data-platform #web-application-firewall
Вопрос:
У нас есть веб-приложение java , развернутое в виртуальной машине Windows server 2019 с tomcat 9.0.37, эта виртуальная машина сильно защищена брандмауэром и работает только с прокси-сервером. Существующее веб-приложение, развернутое в tomcat, подключается к Snowflake с помощью настроек прокси-сервера в конце Url-адреса JDBC:
jdbc:snowflake://xxxxx.eu-central-1.snowflakecomputing.com:443/?db=xxxxxamp;useProxy=trueamp;proxyHost=xxx.xxx.comamp;proxyPort=8080
Это работает идеально.
Теперь в том же tomcat , когда мы развертываем новую бета-версию одного и того же приложения отдельно и используем один и тот же URL-адрес jdbc и реквизиты JDBC(проверенные несколько раз путем сравнения рядом), он долго ждет и показывает ошибку тайм-аута шлюза в журналах :
30-Jun-2021 10:59:15.909 SEVERE [http-nio-8080-exec-2] net.snowflake.client.jdbc.RestRequest.execute Stop retrying since elapsed time due to network issues has reached timeout. Elapsed=84,011(ms), timeout=60,000(ms)
В новой бета-версии нет изменений в коде, касающихся подключения Snowflake. Это точно то же самое. И версия JDBC Jar в обоих приложениях также точно такая же. Даже если мы попытались использовать одно и то же имя контекста приложения , оно все равно показывает одно и то же. Мы пробовали использовать несколько учетных записей snowflake , все они работали с прокси в старом приложении , ничего не работает с прокси в новом бета-приложении.
Мы попробовали инструмент SnowCD Network Diagonistic , он хорошо работает с теми же настройками прокси-сервера, которые передаются в качестве аргумента командной строки. Snowcd С Прокси = Прошел 13 из 13 проверок
Snowcd Без Прокси = Не прошел 27 из 27 проверок
Что дальше мы можем сделать здесь , пожалуйста, предложите любые другие способы устранения неполадок, чтобы найти первопричину.
Примечание: Та же самая новая бета-версия отлично работает с подключением snowflake со всеми другими разработчиками и командами тестирования, которые используют ее в обычной среде без прокси/брандмауэра, включая меня.
Комментарии:
1. Это может показаться глупым, а также не уверенным в вашем часовом поясе, но вчера около 18:30 UTC у Snowflake произошел сбой, из-за которого некоторые клиенты не смогли подключиться. Проблема была решена несколько часов спустя. Вы пробовали подключиться сегодня? На нас это не повлияло, и Снежинка не сказала, с какими настройками возникли проблемы, так что, возможно, прокси-соединения были?
2. @DeanFlinter Не тот случай , мы пытаемся исправить это за последние 10 дней
3. Достаточно справедливо! Предположим, что это работает в какой-то среде разработки или промежуточной среде? Похоже, что прокси/брандмауэр может быть настроен по-разному в этой среде. Может быть, попросить свою сетевую команду перепроверить? Я понимаю, что это не очень помогает, но иногда это простая вещь, которую упускали из виду