Сегодня запутался в том, что у потока своя настройка прокси чекера, у парсеров свои отдельные настройки. Логика "наследования" настроек не вполне очевидна. Что "All" в настройках парсера следует читать как "inherit" от потока. Например, настройка "Reuse proxy between retries" относится скорее к конкретному парсеру, его "личному" прокси-чекеру, нежели к потоку, всему заданию... Ведь поведение конкретного чекера (интервалы, баны) зависит именно от парсера. А настройки всего задания (потока) - это по сути просто число потоков. И всё! Все проксёвые настройки должны относится к прокси-чекерам. Тогда логика будет соблюдена без сложностей с наследованием. В общем, каждому парсеру по своему прокси чекеру. Без наследования и замороки!
ОЧЕНЬ поддерживаю. Bulk/one request катастрофически плохо работают с StromProxy, например, именно из-за отсутствия возможности указать в настройках "Reuse proxy between retries". Для понимания ситуации - сервис выдаёт 4 IP, за которыми ротируются десятки тысяч проксей, и без Reuse - парсинг моментально встаёт колом. С саппортом постарались решить проблему (как всегда очень большая благодарность саппорту за терпение и поддержку), указав Proxy ban time в настройках пресета парсера на 0, но это по тестам никакого толкового результата не даёт, работает как задумано именно Reuse proxy, а его при работе через bulk использовать невозможно.
Есть какие-нибудь новости по subj? А то топчемся на месте, уже разработали всё что можно по кругу минуя задачи парсинга, очень хотелось бы приступить Ну и небольшим доп. стимулом будет необходимость после реализации subj в покупке ещё одной лицензии Enterprise
Реализована возможность задать configPreset в API запросах oneRequest/bulkRequest Переносить найстроку в проксичекеры или раздувать настройки парсеров нецелесообразно
