About Publisher confirms Time

[UncleJuJu]

I have two question for Publisher Confirms Time.

from this blog introducing-publisher-confirms, I have a question for Confirm Time.

a persistent message is confirmed when it is persisted to disk or when it is consumed on every queue.

I vex 2 Confirm's Time which one will faster？

I guess,
if consumer use automatic acknowledgement mode ，or 'consumer deal and manual ack' faster then 'persisted to disk', then line 1 will effect;
if consumer use manual acknowledgement mode and deal and ack no faster then 'persisted to disk’, then line 2 will effect.

Am I right?

so base first question i have second question for Publisher Confirms and Guaranteed Delivery

a client consumes the message from the queue, but confirms are not active,

This one means Consumer use automatic acknowledgement mode?

i think lose persistent messages will happen by Publisher received an ack from Consumer auto ack，and Comsumer maybe down when queue deliver msg and broker down before msg written to disk.

So for Publisher Confirms and Guaranteed Delivery, Publisher need open Confirm and Return, Quese and MSG need durable, And Consumer need use manual acknowledgement mode.

Am I right?

[michaelklishin]

Publisher confirms are generally entirely orthogonal to consumer acknowledgements, just like publishers are unaware of consumers and vice versa.

We cannot speculate as to which event "will be faster", in particular in the presence of multiple queues. By far the best choice for data safety, besides using publisher confirms, would be to also use a quorum queue or a stream (this means using a different client library and protocol, of course).

but confirms are not active,

refers to consumer acknowledgements as far as I can tell, I will update that section to make it clearer, as in the rest of the guides.

Using publisher confirms and then automatic acknowledgements on the consumer end is weird: you claim that your data is important when publishing but then claim the opposite when consuming. So which one is it?

[michaelklishin]

Correct. Number 2 plus replication are covered if you use quorum queues (or streams via messaging protocols, although it is a better idea to use a stream protocol client which has very similar data safety features).

Numbers 1 and 3 are up to applications to use in a way they see fit.

It's always good to see people try to understand all the aspects of distributed (messaging-based) data safety 👏

[UncleJuJu]

I have a question, hope you can help me.
Pre-conditions is Classic Queue durable and MSG durable, Publisher and Consumer has started.
which one is right?

1. P send MSG, First it is persisted to disk then ( ack Publisher and send MSG to Consumer).
2. P send MSG, it is persisting to disk and sending MSG to Consumer together. And if persisting not over yet, Consumer ack to Queue, then Broker ack Publisher.

Maybe I just want to ask Must when persistence is over then Publisher be inform, or will Publisher be inform if the message is consumed first?

My question just about Classic Queue durable and MSG durable：
Is always When persistence is over then Publisher be inform?

[michaelklishin]

Like I said earlier, publishers are NOT aware of or coordinated with consumers. From the Publisher confirms doc guide:

For routable messages, the basic.ack is sent when a message has been accepted by all the queues.
For persistent messages routed to durable queues, this means persisting to disk.
For quorum queues, this means that a quorum replicas have accepted and confirmed the message to the elected leader.

[lhoguin]

There is some nuance in the case of individual queues. For classic queues v1 and v2 the message may get sent to the consumer before it has been written to disk.

In the case of CQ v1, even if we get the message acked before writing to disk, it will still get written to disk, then confirms get processed, and then later on removed when the journal is processed.

In the case of CQ v2, the message may never be written to disk. This does not change the way the message is handled though, confirms will be processed only after the next flushing of buffers to disk. It only reduces the amount of I/O the queue performs.

Then as Michael said, confirms will only be sent once all queues have flushed to disk. The optimisation doesn't change that.

[UncleJuJu]

OK, I get it.Thank you all.I'm so happy to have your help.😊