Nacks and Publisher Acknowledgements

[jo...@signafire.com]

Essentially, it's not clear to me how an application is supposed to recover when handling a nack or when langohr.confirm/wait-for-confirms returns false. It seems to me that the delivery tag that the nack handler receives is only useful if I've been maintaining a map from delivery tags to messages (so that I know which message needs to be retried). Is that a responsibility expected of the application developer? I.e., should I be doing something like (swap! delivery-tag->message assoc (.getNextPublishSeqNo channel) message) before each invocation of langohr.basic/publish? (If so, I'd probably also (swap! delivery-tag->message dissoc delivery-tag) inside of the ack-handler.)

And in the case of langohr.confirm/wait-for-confirms returning false: all I know in that circumstance is that some message failed to send since the last time I called wait-for-confirms. So in order to use wait-for-confirms, should I be maintaining a set of pending messages? Something along the lines of:

(if (wait-for-confirms channel)
  (reset! sent-yet-unconfirmed-messages #{})  ; flush our memory of the recently-sent messages
  (try-resending-the-messages))

I'd really appreciate any guidance you can provide.

-Josh Tilles

P.S. I'm new to AMQP, RabbitMQ, and Langohr, so if I'm going about this the wrong way, feel free to point it out.

[Michael Klishin]

Questions belong to the mailing list.

--
You received this message because you are subscribed to the Google Groups "clojure-rabbitmq" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jo...@signafire.com]

I'm confused—I thought this was the mailing list…

That said, if there's a more appropriate place to ask this question, I'm happy to move there.

[Michael Klishin]

Oops, sorry. Something made me believe it was a Github issue notification.

MK

[Michael Klishin]

On Friday, 11 September 2015 06:17:15 UTC+3, josh@… wrote:

Essentially, it's not clear to me how an application is supposed to recover when handling a nack or when langohr.confirm/wait-for-confirms returns false. It seems to me that the delivery tag that the nack handler receives is only useful if I've been maintaining a map from delivery tags to messages (so that I know which message needs to be retried). Is that a responsibility expected of the application developer? I.e., should I be doing something like (swap! delivery-tag->message assoc (.getNextPublishSeqNo channel) message) before each invocation of langohr.basic/publish? (If so, I'd probably also (swap! delivery-tag->message dissoc delivery-tag) inside of the ack-handler.)

That is one option. See below. 

 

And in the case of langohr.confirm/wait-for-confirms returning false: all I know in that circumstance is that some message failed to send since the last time I called wait-for-confirms. So in order to use wait-for-confirms, should I be maintaining a set of pending messages? Something along the lines of:

(if (wait-for-confirms channel)
  (reset! sent-yet-unconfirmed-messages #{})  ; flush our memory of the recently-sent messages
  (try-resending-the-messages))

I'd really appreciate any guidance you can provide.

There are two primary ways of using publisher confirms in the Java client:

 * Publish one-by-one, waitForConfirms for every message. The easiest and by far least efficient.

 * Publish batches, waitForConfirms for every batch. Republishing has to happen in batches.

 * Use confirm listeners (streaming confirms). Sequences and delivery tags lets you keep track of which messages were nacked.

Langohr doesn't really introduce anything new in that area.