Подтверждение RabbitMQ

[gosolivs]

Может стоит добавить пример подтверждение обработки сообщений? Возможно и Nack.

https://github.com/evrone/go-service-template/blob/46ae5d6ed690206e6d1b8d13b1bb6e52c2cf76bb/pkg/rabbitmq/rmq_rpc/server/server.go#L74
https://github.com/evrone/go-service-template/blob/46ae5d6ed690206e6d1b8d13b1bb6e52c2cf76bb/pkg/rabbitmq/rmq_rpc/client/client.go#L170

[neprja]

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

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

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

[gosolivs]

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

[akirill0v]

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

[neprja]

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

[gosolivs]

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

[neprja]

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

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