Building a RabbitMQ RPC Service in Java: From Client to Server

After learning to distribute time‑consuming tasks with work queues, this section shows how to run a function on a remote machine using the Remote Procedure Call (RPC) pattern built on RabbitMQ.

Client Interface

A simple client class exposes a call method that sends an RPC request and blocks until a response arrives.

FibonacciRpcClient fibonacciRpc = new FibonacciRpcClient();
String result = fibonacciRpc.call("4");
System.out.println("fib(4) is " + result);

Although RPC is common, it can cause confusion when developers cannot tell whether a call is local or a slow remote invocation, leading to unpredictable systems and harder debugging. Follow these guidelines: Clearly separate local and remote calls. Document component dependencies. Handle error cases, e.g., server unavailability. Prefer asynchronous pipelines when possible.

Callback Queue

Implementing RPC with RabbitMQ is straightforward: the client publishes a request and the server replies. The client must provide a callback queue address to receive the response.

callbackQueueName = channel.queueDeclare().getQueue();

BasicProperties props = new BasicProperties.Builder()
    .replyTo(callbackQueueName)
    .build();

channel.basicPublish("", "rpc_queue", props, message.getBytes());
// ... then read the response from callback_queue ...

Import the required class:

import com.rabbitmq.client.AMQP.BasicProperties;

AMQP 0‑9‑1 defines 14 message properties; the most frequently used are: deliveryMode : 2 for persistent, otherwise transient. contentType : e.g., application/json . replyTo : name of the callback queue. correlationId : unique identifier to match responses to requests.

Correlation Id

Instead of creating a separate callback queue per request, assign a unique correlationId to each request and use a single callback queue. When a message arrives, the client checks the correlationId to match it with the original request, discarding unknown IDs.

This approach handles race conditions where a server might crash after processing a request but before sending an acknowledgment; a restarted server may re‑process the request, so the client must treat duplicate responses idempotently.

RPC Workflow Summary

The client sends a message with replyTo (an exclusive callback queue) and a unique correlationId.

The message is published to the rpc_queue queue.

An RPC worker (server) consumes from rpc_queue, processes the request, and publishes the result to the queue named in replyTo.

The client reads from the callback queue, matches the correlationId, and returns the result to the application.

Full Implementation

Fibonacci function used by the server:

private static int fib(int n) {
    if (n == 0) return 0;
    if (n == 1) return 1;
    return fib(n-1) + fib(n-2);
}

Compile the client and server (replace $CP with your classpath):

javac -cp $CP RPCClient.java RPCServer.java

Start the server:

java -cp $CP RPCServer
# => [x] Waiting for RPC requests

Run the client to request a Fibonacci number:

java -cp $CP RPCClient
# => [x] Request fib(30)

Advantages and Limitations

Scalable: launch additional RPCServer instances to handle higher load.

Client simplicity: a single request‑response message, no need for synchronous queue declarations, resulting in one network round‑trip per RPC.

Missing features: handling of server downtime, timeout mechanisms, error propagation to the client, and input validation are not covered.