String. Есть сервер, допустим X. Курл X:5432 до него отрабатывает за секунду, все ок. connect_timeout стоит на 3 секунды.
Мы "отрубаем" сервер "из розетки", курл теперь весит до него с десяток других секунд, НО connect_timeout в три секунды не срабатывает, а продолжает подключиться примерно столько же, сколько курл.
Есть предположение, что в данном случае нужен какой-то таймаут "уровнем выше", мб на уровне ОС? Видимо приложение пытается еще до подключения к БД и использования Connection String "развезолвить" хост с десяток других секунд, как вот этот вот кейс через таймаут ограничить?
Покажыте достаточно полный код, которым подключаетесь (лучшэ — повторяемый, т.е. такой, который запустится у других участников чятика).
Вряд ли смогу показать :/ Там sql_alchemy с psycopg и engine_options = { "connect_args": {"connect_timeout": 3}
Ну, на нет и суда нет. Впрочем, могу посоветовать поискать в коде set_wait_callback. Если найдёте — можэте попытаться всунуть внутрь код таймаута. Или, кстати (лучшэ) — найдите любителя параллелизма и корутинов, который этот set_wait_callback вставил, и заставьте его в этой проблеме разбираться. (После set_wait_callback этот connection_timeout и не должэн работать, есличо).
Впрочем, его мог позвать sqlaclemy_gevent или какая-то другая библиотека для облегчения сопряжэния с green threads и корутинами.
Не нужно gevent тащить в 2023м то году, если это не дикое легаси. Тем более что sqlalchemy уже поддерживает asyncio.
Я сильно подозреваю, что sqlalchemy/asyncio тожэ поставит set_wait_callback...
Обсуждают сегодня