search

achilleasa / dart_amqp

Dart AMQP client implementing protocol version 0.9.1
MIT License
79 stars 40 forks source link

How to Confirm Publish e.g. Message Sent Successfully? #60

Closed DaleBeckles closed 3 years ago

DaleBeckles commented 3 years ago

FIrst off, thanks for all your work on dart_amqp. You have saved me countless hours!

To achieve high reliability, I want to confirm i.e. acknowledge both message send and message consume. My question is how do you confirm that a message has been successfully sent/published?

I have read the RabbitMQ docs at https://www.rabbitmq.com/confirms.html#publisher-confirms and have been unable to make this work. I have tried using [channel.ack()] and see no properties as recommended in your docs to instead use [MessageProperties], but I have been unsuccessful. Additionally, there is no doc on the queue [noWait] flag, which if I set to true "hangs" my app. What is the purpose of [noWait]?

Thanks in advance for any assistance with these questions.

achilleasa commented 3 years ago

AFAICT the confirms message class seems to be a channel(?) class extension (it's not mentioned in the XML spec which was used to generate the classes used by this library).

Should be relatively easy to add support for once if I can find (not mentioned in the docs; I will need to find a client that uses this feature and extract them from there) the right values for the message class/method IDs.

achilleasa commented 3 years ago

Right, so the definitions are here. I will try to block off some time to get this into the client.

DaleBeckles commented 3 years ago

Thank you for your prompt response and consideration. Please let me know if I can assist in any way e.g. testing. Also, what is the purpose of [noWait] in a queue?

achilleasa commented 3 years ago

I have pushed a PR which implements published confirms. Can you give it a go and let me know if it works as expected?

The noWait flag instructs the broker not to respond to a the command that the client just sent. Typically amqp interactions are like so: client sents command X, broker responds with X_OK. If this flag is set, the broker will report errors by raising an exception at the channel or connection level.

Now that I think about it, the library probably does not handle noWait correctly because all these methods return Futures back which won't be ever completed when noWait is set (this probably explains why setting the flag caused your app to hang). I will take another look at this and fix it in a separate PR.