А входящих потоков у вас N. Каждый из них кидает в очередь сообщение и открывает туннель (RPC), по которому ждёт ответа (и последующие не дожидаются). Это неправильно - зачем им что-то ждать, если сам пользователь ушёл. Тут вообще не нужен RPC и тогда, скорее всего, никаких таймаутов вы ловить не будете.
Тогда я и говорю - вам нужно отказаться от RPC, он не предназначен для таких длительных процессов. У RPC есть свой таймаут, скорее всего, срабатывает именно он.
А, я подумал, что у вас RPC и именно в нём таймаут возникает.
Тогда я что-то не понимаю, как у вас сейчас всё устроено и где возникает проблема.
В consumer_timeout должно быть значение, которое превышает максимальное время обработки одного сообщения. Т.е. это время, за которое вы должны отдать ACK. Но при чём тут тогда следующие сообщения и какое соединение там закрывается? Если у вас consumer работает в один поток, то Rabbit спокойно принимает сообщения в очередь, они там лежат сколько угодно долго, пока их кто-то не возьмёт в обработку, и только в этот момент начинает тикать consumer_timeout.
ProjectSoft, ровно наоборот - новичка не нужно перегружать устаревшими многословными конструкциями. Если у него возникнет необходимость поддерживать IE6, тогда и изучит то, что в нём работает.
Единственное усложнение при использовании fetch - промисы. Но это база современного JS, их придётся изучать в любом случае.
Вы правы, наверное. Зависит от предметной области - если запросы пришли с разницей в час, должен ли быть обработан второй как новый или нет? Если должен, то да, лочить на максимально допустимые N секунд, в которые нельзя присылать дубли. Если не должен, то вообще другая проверка должна быть и данные о том, что запрос с конкретными параметрами уже обработан нужно сохранять навсегда, а мьютекс можно будет сразу освобождать после первой обработки - пусть второй скрипт его захватывает, но внутри сработает проверка на уникальность.
А где текст задания-то? Вы ожидаете, что кто-то пойдёт гуглить, что это за сайт, потом там зарегистрируется, потом дойдёт до этого задания, решит его и вернётся сюда вам всё рассказать?
Автор всерьёз борется с Матрицей (почитайте его прошлые вопросы). Из этого два противоречащих друг другу следствия: а) никакие трудности его не остановят и б) никакой процессор он никогда не сделает.
Просто имейте это в виду, если решите вступить в обсуждение.
