@Escobar said in "getaddrinfo () thread failed to start":
@UserTrue @Fox Можно ли это решить в следующем обновлении Bas?
If the algorithm for error occurrence is determined, then most likely Yes
С такой же проблемой сегодня столкнулся. Поставил сон в 1 секунду между запросами и ошибки пропали. Похоже в 1 потоке нельзя запросы без задержек выполнять.
@atomexpert said in "getaddrinfo () thread failed to start":
С такой же проблемой сегодня столкнулся. Поставил сон в 1 секунду между запросами и ошибки пропали. Похоже в 1 потоке нельзя запросы без задержек выполнять.
Как можно повторить эту ошибку?
@Fox Попробуйте какие-нибудь запросы выполнять в многопотоке без задержек. У меня было запущенно 17 потоков, каждый из которых запускал по 10 асинхронных функций. В каждой функции был цикл While, который брал ID из ресурса и делал запрос к VK. Изначально задержек в цикле вообще не было, ошибки примерно через минуту начинали сыпаться, ругаясь на прокси (Failed to connect). Думал в них дело, убрал прокси и появилась ошибка, которая в этой теме. Перед запросом поставил задержку от 500 до 1000 мск и все ошибки пропали.
@atomexpert said in "getaddrinfo () thread failed to start":
@Fox Попробуйте какие-нибудь запросы выполнять в многопотоке без задержек. У меня было запущенно 17 потоков, каждый из которых запускал по 10 асинхронных функций. В каждой функции был цикл While, который брал ID из ресурса и делал запрос к VK. Изначально задержек в цикле вообще не было, ошибки примерно через минуту начинали сыпаться, ругаясь на прокси (Failed to connect). Думал в них дело, убрал прокси и появилась ошибка, которая в этой теме. Перед запросом поставил задержку от 500 до 1000 мск и все ошибки пропали.
Запросы были с разных ip? Может вас сервер заблочил за слишком частые запросы?
@Fox Нет, дело явно не в блокировке. Сначала с прокси пробовал, IP были разные на каждом аккаунте. Потом без прокси с 1 ip. Тестил как с VDS так и с ПК, в обоих случаях через минуту появлялось много ошибок. Добавление тайм аута решило проблему полностью. Сейчас ошибок нету, как с использованием прокси, так и без них.
@atomexpert Причём ошибки возникали сразу на всех потоках, при выполнении практически всех Post/Get запросов, что навело на подозрение о том, что проблемы скорее всего с HTTP клиентом баса из за слишком частого выполнения этих запросов.
Я тоже оказался в числе счастливчиков со своим многопоточным скриптом, которые получали данную ошибку и не только ее. При HTTP запросах вылетают также такие ошибки:
Error: read ECONNRESET
Еще вот такая
Error: 7096:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:c:\ws\deps\openssl\openssl\ssl\record\ssl3_record.c:677:
По поводу последней ошибки на форумах пишут о конфликте протоколов SSL и TLS и/или их версий. Пишут, что нужно дать приоритет TLSv1. Также были подозрения на стабильность соединения, антивирус.
@atomexpert said in "getaddrinfo () thread failed to start":
@atomexpert Перед запросом поставил задержку от 500 до 1000 мск и все ошибки пропали.
Мне также пришла идея использовать задержку, но в твоем случае если скрипт работает достаточно долго или имеет большое число потоков, то это рано или поздно все равно может привести к ошибке (по теории вероятности). И в этом случае лучше сделать задержку через привязку к номеру потока, например:
номер потока * 100мс
Так все запросы будут выполняться строго последовательно.
Насколько я понял, у HTTP запросов есть одна проблема - привязка ответа к конкретному запросу происходит только по времени - по времени, когда открыт сокет. Если мы делаем одновременно много запросов на один адрес, то клиент может не понять какой ответ принадлежит какому запросу и я получил этому подтвержение на собственном опыте, работая в БАС.
У меня скрипт работал в 13 потоков и в каждом потоке я одновременно делал абсолютно один и тот же запрос и должен был получать один и тот же ответ в формате json, примерно такой:
{[данные1],[данные2],[данные3]}
Но в некоторых потоках я обнаружил что данные являются не полными, либо излишними, т.е. вот так:
поток 1: {[данные1],[данные2],[данные3],[данные1]}
поток 2: {[данные1],[данные2]}
@botovod said in "getaddrinfo () thread failed to start":
Насколько я понял, у HTTP запросов есть одна проблема - привязка ответа к конкретному запросу происходит только по времени - по времени, когда открыт сокет. Если мы делаем одновременно много запросов на один адрес, то клиент может не понять какой ответ принадлежит какому запросу и я получил этому подтвержение на собственном опыте, работая в БАС.
У меня скрипт работал в 13 потоков и в каждом потоке я одновременно делал абсолютно один и тот же запрос и должен был получать один и тот же ответ в формате json, примерно такой:
{[данные1],[данные2],[данные3]}
Но в некоторых потоках я обнаружил что данные являются не полными, либо излишними, т.е. вот так:
поток 1: {[данные1],[данные2],[данные3],[данные1]}
поток 2: {[данные1],[данные2]}
Если я вас правильно понял, то что бы повторить эту ошибку, нужно создать скрипт в котором потоки будут отправлять запрос на один и тот же сервер и просто проверять ответ. При запуске в 20 потоков будут происходить ошибки?
Подойдёт любой сервер или только тот, с которым работаете именно вы? Потому что я почти во всех скриптах на запросах применял логику, когда огромное (под 400) число потоков посылало запросы к одному и тому же серверу, и не сталкивался с подобными проблемами.
@Fox Проблема возникает при запросе к серверам Binance.com. Для простоты эксперимента можно попробовать сделать ГЕТ запросы без авторизации (незнаю имеет ли авторизация значение, вполне вероятно что может влиять на результат), для этого регистрация не потребуется.
Запрос для тестирования можно делать например по этому адресу (у него ответ более объемный): https://fapi.binance.com/fapi/v1/exchangeInfo
ограничения:
1200 запросов в минуту
100 ордеров за 10 секунд
200 000 ордеров за 24 часа
И подождать нужно несколько часов. Ошибка возникает достаточно не часто.
Error: read ECONNRESET
"ECONNRESET" означает, что другая сторона разговора TCP внезапно закрыла свой конец соединения.
@botovod said in "getaddrinfo () thread failed to start":
И подождать нужно несколько часов. Ошибка возникает достаточно не часто.
Я попробую повторить эту ошибку, хоть и алгоритм возникновения слишком размытый. Смотрите, если это ошибка BAS, то проблема должна распространятся на все сервера, а не только на один сайт. С binance.com у меня есть действующий проект на ноде, он работает с 2019 года. Подобных ошибок при запросах я не получал ни разу.
Итак, функция getaddrinfo() используется для получения ip по имени домена. Ошибка скорее всего происходит при использовании неподдерживаемых прокси (BAS поддерживает только http и socks5 прокси)
