Publisher confirms in RabbitMQ - Step-by-Step Execution

Process Flow - Publisher confirms

Start Publisher

↓

Enable Publisher Confirms

↓

Send Message to Exchange

↓

Wait for Broker Ack/Nack

↓

Confirm Success

↓

Continue or Retry

The publisher sends a message and waits for the broker to confirm if it was received successfully (ack) or not (nack).

Execution Sample

RabbitMQ

channel.confirmSelect()
channel.basicPublish(exchange, routingKey, props, message)
channel.waitForConfirms()

Enable confirms, publish a message, then wait for confirmation from RabbitMQ.

Process Table

Step	Action	Message Sent?	Broker Response	Publisher State
1	Enable publisher confirms	No	N/A	Waiting to send
2	Publish message to exchange	Yes	Waiting for ack/nack	Waiting for confirmation
3	Broker sends ack	Yes	Ack received	Message confirmed
4	Publish next message or finish	Depends	N/A	Ready for next message

💡 Publisher confirms received ack, message delivery confirmed.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
message_sent	false	true	true	true
broker_response	none	waiting	ack	ack
publisher_state	idle	waiting_confirm	confirmed	confirmed

Key Moments - 3 Insights

Why does the publisher wait after sending the message?

The publisher waits to receive an ack or nack from the broker to know if the message was successfully received, as shown in step 2 and 3 of the execution table.

What happens if the broker sends a nack?

If a nack is received, the publisher knows the message was not confirmed and can retry or handle failure. This is the alternative path after step 3 in the concept flow.

Can the publisher send multiple messages before waiting for confirms?

Yes, but each message will be confirmed in order. The example shows waiting after one message for simplicity, but confirms can be handled asynchronously.

Visual Quiz - 3 Questions

Look at the execution table, what is the publisher state after step 2?

A Idle

B Message confirmed

C Waiting for confirmation

D Finished

💡 Hint

Check the 'Publisher State' column at step 2 in the execution table.

At which step does the broker send an ack?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Broker Response' column in the execution table.

If the broker sends a nack instead of an ack, what should the publisher do?

A Ignore and continue

B Retry or handle failure

C Shutdown immediately

D Send a duplicate message without waiting

💡 Hint

Refer to the concept flow where nack leads to 'Handle Failure'.

Concept Snapshot

Publisher confirms in RabbitMQ:
- Enable confirms with channel.confirmSelect()
- Publish message with basicPublish()
- Wait for ack/nack with waitForConfirms()
- Ack means message received, nack means failure
- Use confirms to ensure reliable delivery

Full Transcript

Publisher confirms in RabbitMQ allow the publisher to know if a message was successfully received by the broker. The publisher first enables confirms, then sends a message. After sending, it waits for the broker to send an acknowledgement (ack) or negative acknowledgement (nack). If ack is received, the publisher knows the message was delivered successfully. If nack is received, the publisher can retry or handle the failure. This process helps ensure reliable message delivery in RabbitMQ.

Practice

1. What does enabling publisher confirms in RabbitMQ do?

easy

A. It automatically retries sending messages on failure.

B. It encrypts messages before sending.

C. It tells you if RabbitMQ accepted your message.

D. It queues messages without sending them.

Solution

1. Step 1: Understand the purpose of publisher confirms

   Publisher confirms notify the sender if the message was accepted by RabbitMQ.

2. Step 2: Compare with other options

   Retrying, encrypting, or queuing without sending are unrelated to confirms.

3. Final Answer:

   It tells you if RabbitMQ accepted your message. -> Option C

4. Quick Check:

   Publisher confirms = message acceptance notification [OK]

Hint: Publisher confirms confirm message acceptance by RabbitMQ [OK]

Common Mistakes:

• Confusing confirms with message encryption
• Thinking confirms retry messages automatically
• Assuming confirms delay message sending

2. Which method must be called on a RabbitMQ channel to enable publisher confirms?

easy

A. enableConfirms()

B. setConfirmMode()

C. startConfirm()

D. confirmSelect()

Solution

1. Step 1: Recall the correct method name

   The method to enable confirms on a channel is confirmSelect().

2. Step 2: Verify other options

   Other method names like enableConfirms() or startConfirm() do not exist in RabbitMQ API.

3. Final Answer:

   confirmSelect() -> Option D

4. Quick Check:

   Enable confirms = confirmSelect() [OK]

Hint: Enable confirms by calling confirmSelect() on the channel [OK]

Common Mistakes:

• Using incorrect method names like enableConfirms()
• Forgetting to call confirmSelect() before publishing
• Confusing confirmSelect() with waitForConfirms()

3. Given this code snippet, what will waitForConfirms() return if the message was accepted?

channel.confirmSelect();
channel.basicPublish(exchange, routingKey, props, body);
boolean confirmed = channel.waitForConfirms();
System.out.println(confirmed);

medium

A. false

B. true

C. null

D. Exception thrown

Solution

1. Step 1: Understand waitForConfirms() behavior

   This method returns true if RabbitMQ accepted the message, false otherwise.

2. Step 2: Given the message was accepted

   The variable confirmed will be true, so printing it outputs 'true'.

3. Final Answer:

   true -> Option B

4. Quick Check:

   Message accepted = waitForConfirms() returns true [OK]

Hint: waitForConfirms() returns true if message accepted [OK]

Common Mistakes:

• Expecting waitForConfirms() to return false on success
• Assuming it returns null or throws exception on success
• Confusing waitForConfirms() with asynchronous callbacks

4. What is wrong with this code snippet for enabling publisher confirms?

channel.basicPublish(exchange, routingKey, props, body);
channel.confirmSelect();
boolean confirmed = channel.waitForConfirms();

medium

A. confirmSelect() must be called before basicPublish()

B. waitForConfirms() cannot be called after publishing

C. basicPublish() requires a callback parameter

D. confirmSelect() should be called after waitForConfirms()

Solution

1. Step 1: Check order of method calls

   confirmSelect() must be called before publishing to enable confirms.

2. Step 2: Identify the error

   In the snippet, confirmSelect() is called after basicPublish(), so confirms are not enabled when publishing.

3. Final Answer:

   confirmSelect() must be called before basicPublish() -> Option A

4. Quick Check:

   Enable confirms before publishing [OK]

Hint: Call confirmSelect() before publishing messages [OK]

Common Mistakes:

• Calling confirmSelect() after publishing
• Thinking waitForConfirms() disables confirms
• Believing basicPublish() needs a callback for confirms

5. You want to ensure your application only proceeds after RabbitMQ confirms message acceptance. Which sequence of calls correctly implements this using publisher confirms?

hard

A. channel.confirmSelect(); channel.basicPublish(...); channel.waitForConfirms();

B. channel.basicPublish(...); channel.waitForConfirms(); channel.confirmSelect();

C. channel.waitForConfirms(); channel.confirmSelect(); channel.basicPublish(...);

D. channel.basicPublish(...); channel.confirmSelect(); channel.waitForConfirms();

Solution

1. Step 1: Enable confirms before publishing

   Call confirmSelect() first to enable confirms on the channel.

2. Step 2: Publish the message and wait for confirmation

   After basicPublish(...), call waitForConfirms() to block until RabbitMQ confirms acceptance.

3. Final Answer:

   channel.confirmSelect(); channel.basicPublish(...); channel.waitForConfirms(); -> Option A

4. Quick Check:

   Enable confirms, publish, then wait [OK]

Hint: Enable confirms, publish, then waitForConfirms() [OK]

Common Mistakes:

• Calling confirmSelect() after publishing
• Waiting for confirms before publishing
• Not calling waitForConfirms() at all