Implementing RPC client and server in RabbitMQ - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is RPC in the context of RabbitMQ?

RPC (Remote Procedure Call) allows a client to send a request message to a server and wait for a response, enabling communication between distributed systems.

beginner

Which RabbitMQ feature is commonly used to implement RPC?

The 'reply_to' queue and 'correlation_id' properties are used to match requests with responses in RabbitMQ RPC.

intermediate

What role does the 'correlation_id' play in RabbitMQ RPC?

It uniquely identifies the request so the client can match the response to the correct request.

intermediate

How does the RPC server know where to send the response?

The server reads the 'reply_to' property from the request message, which contains the queue name for the response.

intermediate

Why should the RPC client use a unique callback queue?

To receive responses only for its own requests and avoid mixing messages from other clients.

In RabbitMQ RPC, what property does the client set to receive the server's response?

A reply_to

B content_type

C delivery_mode

D expiration

The 'reply_to' property tells the server which queue to send the response to.

What is the purpose of the 'correlation_id' in RabbitMQ RPC?

A To identify the client

B To set message priority

C To match the response with the request

D To specify message expiration

The 'correlation_id' helps the client match the response to the original request.

Which queue type is typically used by the RPC client to receive responses?

A Durable queue

B Exclusive callback queue

C Fanout queue

D Dead-letter queue

An exclusive callback queue is used so only the client receives its responses.

What happens if the RPC server does not set the 'correlation_id' in the response?

A The client cannot match the response to the request

B The message is discarded

C The server crashes

D The response is sent to all clients

Without 'correlation_id', the client cannot identify which request the response belongs to.

Which RabbitMQ exchange type is commonly used to send RPC requests?

A Fanout exchange

B Topic exchange

C Headers exchange

D Direct exchange

Direct exchange routes messages to queues based on routing keys, suitable for RPC requests.

Explain how an RPC client and server communicate using RabbitMQ.

Think about the message properties and queues involved.

Describe the purpose of the 'reply_to' and 'correlation_id' properties in RabbitMQ RPC.

These properties help the client and server coordinate messages.

Practice

1. What is the main role of the RPC server in RabbitMQ RPC communication?

easy

A. To store messages permanently without processing

B. To send requests and wait for responses

C. To receive requests, process them, and send back responses

D. To monitor network traffic between clients

Solution

1. Step 1: Understand RPC server role

   The RPC server listens for requests on a queue and processes them.

2. Step 2: Identify server response behavior

   After processing, the server sends the result back to the client via a reply queue.

3. Final Answer:

   To receive requests, process them, and send back responses -> Option C

4. Quick Check:

   RPC server handles requests and replies [OK]

Hint: Server processes requests and replies, client sends requests [OK]

Common Mistakes:

• Confusing client and server roles
• Thinking server only stores messages
• Assuming server sends requests

2. Which of the following is the correct way to declare a callback queue for RPC replies in Python pika client?

easy

A. channel.queue_declare(queue='rpc_queue')

B. result = channel.queue_declare(queue='', exclusive=True)

C. channel.basic_publish(exchange='', routing_key='rpc_queue')

D. channel.basic_consume(queue='rpc_queue', on_message_callback=callback)

Solution

1. Step 1: Identify callback queue declaration

   For RPC replies, a temporary exclusive queue is declared with empty name and exclusive=True.

2. Step 2: Match syntax with pika usage

   Using queue_declare with queue='' and exclusive=True creates a unique callback queue.

3. Final Answer:

   result = channel.queue_declare(queue='', exclusive=True) -> Option B

4. Quick Check:

   Exclusive empty queue for callback = result = channel.queue_declare(queue='', exclusive=True) [OK]

Hint: Use empty queue name with exclusive=True for callback queue [OK]

Common Mistakes:

• Declaring fixed queue name for callback
• Using basic_publish instead of queue_declare
• Not setting exclusive=True for callback queue

3. Given this Python RPC client snippet, what will be printed?

corr_id = str(uuid.uuid4())
channel.basic_publish(
    exchange='',
    routing_key='rpc_queue',
    properties=pika.BasicProperties(
        reply_to=callback_queue,
        correlation_id=corr_id
    ),
    body='5'
)
print('Sent request with correlation_id:', corr_id)

medium

A. Sent request with correlation_id:

B. Sent request with correlation_id: rpc_queue

C. Sent request with correlation_id: 5

D. Error: correlation_id not defined

Solution

1. Step 1: Understand correlation_id assignment

   corr_id is assigned a new UUID string using uuid.uuid4(), which is random.

2. Step 2: Analyze print statement output

   The print outputs the fixed string plus the generated corr_id value.

3. Final Answer:

   Sent request with correlation_id: <random UUID> -> Option A

4. Quick Check:

   corr_id is UUID string printed [OK]

Hint: corr_id is a UUID string, printed as is [OK]

Common Mistakes:

• Confusing correlation_id with routing_key
• Printing message body instead of corr_id
• Assuming correlation_id is undefined

4. In this RPC server code snippet, what is the main error?

def on_request(ch, method, props, body):
    n = int(body)
    response = fib(n)
    ch.basic_publish(
        exchange='',
        routing_key=props.reply_to,
        properties=pika.BasicProperties(correlation_id=props.correlation_id),
        body=str(response)
    )
    ch.basic_ack(delivery_tag=method.delivery_tag)

channel.basic_consume(queue='rpc_queue', on_message_callback=on_request)

medium

A. Missing call to start consuming messages

B. Incorrect use of correlation_id property

C. No acknowledgment of message delivery

D. Using wrong queue name in basic_consume

Solution

1. Step 1: Check message consumption setup

   basic_consume is set but start_consuming() is not called to begin processing.

2. Step 2: Verify other parts

   Correlation_id usage and ack are correct; queue name matches.

3. Final Answer:

   Missing call to start consuming messages -> Option A

4. Quick Check:

   start_consuming() needed to process messages [OK]

Hint: Always call start_consuming() after basic_consume [OK]

Common Mistakes:

• Forgetting start_consuming() call
• Misusing correlation_id property
• Not acknowledging messages

5. You want to implement an RPC client that sends multiple requests concurrently and matches replies correctly. Which approach best ensures correct matching of replies to requests?

hard

A. Create a new reply queue for each request without correlation_id

B. Send all requests with the same correlation_id to simplify matching

C. Use a single shared reply queue without correlation_id

D. Use a unique correlation_id for each request and check it on reply

Solution

1. Step 1: Understand concurrency in RPC client

   Multiple requests need unique IDs to identify replies correctly.

2. Step 2: Evaluate options for reply matching

   Using unique correlation_id per request allows client to match replies properly.

3. Final Answer:

   Use a unique correlation_id for each request and check it on reply -> Option D

4. Quick Check:

   Unique correlation_id matches replies to requests [OK]

Hint: Assign unique correlation_id per request for reply matching [OK]

Common Mistakes:

• Using same correlation_id for all requests
• Not using correlation_id at all
• Creating many reply queues unnecessarily