Pull to refresh

Comments 7

Так из коробки же, если коньюмер упал, сообщение вернется в ready и его подхватит другой, или оно останется ждать

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

Если сообщение содержит неверные данные и не может быть по этой причине быть обработанным, тогда возврат в очередь может заблокировать весь поток. Лучше создавать новое сообщение которое попадёт в конец очереди.

А не надо его туда возвращать. Делайте ack и в лог ошибку. Или сообщение в другую очередь, которую слушает приложение и обрабатывает. Зачем возвращать туда, где его некому обрабатывать?

С мобилки не смог найти, но помню что такой вопрос решался через ttl, оттуда во вторую очередь с большим ttl и оттуда обратно в первую. Не помню как с количеством раз решалось, наверное количеством очередей. Но в Вашем случае решение на уровне приложения, а не очереди. Те в каждом консьюмере надо решать вопрос отдельно.

Да, в моём случае очереди полностью управляются со стороны приложения. Соответственно есть "Базовый Consumer" от которого наследуются остальные.

Это пока у Вас относительный монолит и одна команда.

Sign up to leave a comment.

Articles