Чем принципиально отличается ack от reject (requeue=false)? Оба же удаляют сообщения

из очереди?

Во-первых, лучше использовать nack, а не reject. Во-вторых, nack позволит перевести сообщение в dlq, а ack — нет.

А разве не реджект в dlx уводит?

Reject обрабатывается в dlx, reject это отклонение сообщения, а аск - потдверждение обработки

Спасибо за ответ. Если отколенное сообщение больше точно не нужно и не хочется занимать место в памяти (диске) отклонёнными сообщениями, то нужно просто ack отправить?

Под отклонением тут понимают "невозможность десериализации сообщения" например, а не бизнес ошибки

Лучше сделать reject. Сейчас вам эти сообщения не нужны а завтра вы захотите собирать эти отклонённые сообщения в отдельную очередь

Бизнес проблемы и реджект ну незнаааю

Ощущение что вы вообще всё неверно написали

Есди не доступна бд для дальнейшей обработки - то nack. Есди фундаментальная ощибка то reject. Если отработано успешно то ack. Вот и вся логика

Если обычное сообщение из-за скидывается на диск, то очередь из отклонённых тоже будет скидываться на диск или это отдельно настраивается?

Ну вы можете пока их не собирать, можете сразу складывать в отдельную очередь. Тут уже как захотите

А если сообщение не отработано и поздно что-то делать, время ответа упущено, ответ больше не нужен. Тогда что?

Звучит как ттл

Он и есть

И он, и nack, у них же одинаковые свойства за исключением дефолта и того, что nack может накнуть батч, а reject — нет.

Что значит вообще? ack подтверждает обработку и выкидывает сообщение, nack — отклоняет одно или батч сообщений и применяет правила, заложенные в очереди: если есть биндинг к dlq, то сообщение(я) уйдут туда.

Вообще - это значит, что я не хочу анализировать очередь из отклонённых сообщений, особенно не хочу заботится о переполнение очереди, памяти, диска и т. п. отклонёнными сообщениями. Если нет биндинга отклонённых сообщений в dlq, то поведение ack и reject (requeue=false) будет одинаковое?

Я не вам отвечал.

Перепутал )) Сорян ))

Стикер

Понял, спасибо. Вот сделали бы в rmq response (код) вместо ack, nack, reject и т. п., было бы понятней. Если есть очередь от отклонённых сообщений, то по смыслу должна быть и очередь из обработанных. Существует ли такая?

Стикер

Стикер

Я просто не встречал на практике использования nack required false, где нак не возвращает сообщение в очередь. Поэтому совсем не понял, не знал что у нака есть признак required

Стикер

Может, просто батчи на кролике не делали. Там без nack(multiple = true, requeue = false) никак.

Обычно накать батчами не приходится, достаточно поштучного нака на батчевый ак

И он получается также откидывается в dlx?

От логики зависит, да. У нас просто была система, которая тоже умела батчами транзакционно принимать, поэтому нам подходило.

Да, весь батч.

Для регистрации отклонённых сообщений тоже должен быть лог в приложении, однако сделали же дополнительную очередь. Поэтому, как по мне, если есть очередь для отклонённых сообщений, то должна быть аналогичная очередь и для обработанных. Или, наоборот, не должно быть очереди, ни для отклонённых сообщений, ни для обработанных, т. е. полагаться только на логи приложения. Это мои общие рассуждения из принципа "наименьшего удивления". В любом случае приходится полагаться на реальную реализацию, а не мои хотели и ожидания.

Стикер

Вы правы. Всегда приходится смотреть на что-то новое через призму своих знаний. Аналогичный вопрос для необработанных сообщений А зачем она? Её же тоже нужно как-то обрабатывать: акать, реджектить и т. п., как-то очищать, чтобы память и диск не занимать.

Стикер

Если вы успешно отработали сообщение, то его содержимое вам больше не нужно (за редкими исключениями). Если неудачно - то ещё как пригодится: снова попробовать, переслать в фолбэк-очередь итп

Не нужно в одном конкретном примере ретрай-очереди. На таких свет клином не сошёлся.

Это самый частый пример использования. Зачем с этим спорить и еще больше запутывать человека — непонятно.

В моем опыте работы с кролем и dlq это не самый частый пример использования.

Для удачных - что-то типа лога для отладки и анализа инцидентов. Для неудачных есть же reject(requeue=True). Зачем ещё одна дополнительная очередь?

Стикер

Кролик не лог и не бд. Не надо его юзать в этом назначении.

Это понятно, речь же шла о ретрай.

Представьте что ошибка в самом сообщении и повторная обработка ее не решит. Возвращать такое сообщение в голову равноценно тому чтобы повесить весь консюмер

Кролик не может в одной очереди хранить сообщения, которые нужно отдать сейчас, и сообщения с delay. Иначе говоря, delay — это свойство очереди, а не сообщения. Поэтому оставить сообщение в этой очереди постоять не выйдет. Его надо перенести.

Можно добавить кастомный хэдер со счетчиком ретраев и т. п.

Так ваш счетчик ретраев без делэя за микросекунды перешагнет порог. Какой в этом смысл? Обычно системы, с которыми ваш консьюмеры общаются, могут восстановиться не сразу, и вы просто застрянете на одном месте да еще все сообщения повыкидываете зря.

Так если консьмер умер, то некому будет и отправлять сообщение в начало очереди, не будет акать и выкидывать сообщения из очереди.

Консьюмер не должен умирать.

Если консюмер умер, то очереди будет плохо, да

В идеальном мире, с высокой доступность консьмер в 2024 и т. п., не должно быть ошибок в сообщении. . Отсутствие ошибок в сообщении как по мне проще обеспечить, чем 100% аптайм.

Хм. Это очень смелое и в корне неверное заявление.

Уверен, что вы знаете rabbitmq гораздо лучше меня поэтому пытаюсь разобраться и понять, что и как. Не более.

При этом написали, что возможны ошибки в сообщении. Мне кажется, что отсутствие ошибок в сообщении добиться проще, чем достаточно высокий аптайм

Нет, я привел ошибку в сообщении как один из примеров - тривиальный достаточно.