Подтверждение RabbitMQ about go-clean-template

[neprja]

Также можно autoAck в channel.Consume в true поставить. Чтобы вообще не писать Ack, раз он не нужен в этом месте.

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

[neprja]

Здесь я не совсем уверен что поступил правильно, но моя логика была следующей:
Я использую Кролик исключительно как транспорт. Вся бизнес-логика на стороне приложения. В RPC паттерне важен сам факт того что сообщение доставлено до сервера, если клиент не получит ответ более 2 секунд (по дефолту), запрос закончится ошибкой timeout и что дальше с этим делать решает бизнес-логика на стороне клиента.

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

Ack и Nack хорошо подходят для асинхронного взаимодействия, но на мой взгляд не очень применимы при синхронном (в RPC паттерне). Я могу ошибаться.

[gosolivs]

@akirill0v @FedotovMaxim, что думайте?

[akirill0v]

На acknowledge базируется работа с RabbitMQ и без этого с сообщениями будет происходить беда. Лучше использовать механизм подтверждения доставки чтобы они не дублировались, не оставались в "Кролике" и не уходили в другие консьюмеры.

[neprja]

Так и есть, он используется. Тут вопрос скорее в том что Nack не используется)

[gosolivs]

Также можно autoAck в channel.Consume в true поставить. Чтобы вообще не писать Ack, раз он не нужен в этом месте.