Implementing RPC client and server in RabbitMQ - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

RPC Server Response Behavior

Given a RabbitMQ RPC server that receives a request and replies with the square of the number sent, what will be the output on the client side if the client sends the number 5?

RabbitMQ

Client sends: 5
Server computes: 5 * 5
Server replies with the result

A 10

B 5

C 25

D Error: No response

💡 Hint

Think about what the server does with the number it receives.

The server squares the number 5, so the client receives 25 as the response.

❓ Configuration

intermediate

Correct Queue Declaration for RPC Server

Which queue declaration is correct for a RabbitMQ RPC server to receive requests and send replies properly?

A channel.queue_declare(queue='rpc_queue', durable=True, exclusive=True)

B channel.queue_declare(queue='rpc_queue')

C channel.queue_declare(queue='rpc_queue', auto_delete=True)

D channel.queue_declare(queue='rpc_queue', exclusive=True, auto_delete=True)

💡 Hint

The queue should be shared (not exclusive) for multiple clients.

The RPC server queue should be declared simply to receive requests; exclusive flags can interfere with multiple clients.

🔀 Workflow

advanced

Order of Steps in RPC Client Request

What is the correct order of steps a RabbitMQ RPC client follows to send a request and receive a response?

A 1,3,2,4

B 3,1,2,4

C 2,1,3,4

D 1,2,3,4

💡 Hint

Think about setting up the response channel before sending the request.

The client first declares the callback queue, then starts consuming from the callback queue, then sends the request with correlation ID and reply_to, and finally waits for the matching response.

❓ Troubleshoot

advanced

RPC Client Does Not Receive Response

A RabbitMQ RPC client sends a request but never receives a response. Which of the following is the most likely cause?

A The server did not send a reply with the correct correlation ID

B The client did not declare the request queue

C The client used a durable queue for the callback queue

D The server queue was declared as exclusive

💡 Hint

The client waits for a response with a matching correlation ID.

If the server replies without the correct correlation ID, the client will ignore the response and appear to never receive it.

✅ Best Practice

expert

Best Practice for Handling Multiple RPC Requests Concurrently

What is the best practice to handle multiple concurrent RPC requests efficiently in a RabbitMQ server?

A Set the RPC queue to auto-delete after each request

B Create a new queue for each client request

C Use a single-threaded server to process requests one by one

D Use multiple worker threads or processes consuming from the same RPC queue

💡 Hint

Think about scaling the server to handle many requests at once.

Using multiple workers consuming from the same queue allows parallel processing of RPC requests, improving throughput and responsiveness.

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