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