You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remote procedure call with RabbitMQ consists in a client sending a request message and a server replying with a response message.
171
-
Both the RPC client and server are _client applications_ and the messages flow through the broker.
172
-
The RPC client must send a reply-to queue address with the request.
173
-
The RPC server uses this reply-to queue address to send the response.
174
-
There must also be a way to correlate a request with its response, this is usually handled with a header that the RPC client and server agree on.
170
+
Request/response with RabbitMQ consists in a requester sending a request message and a responder replying with a response message.
171
+
Both the requester and responder are _client applications_ and the messages flow through the broker.
172
+
The requester must send a reply-to queue address with the request.
173
+
The responder uses this reply-to queue address to send the response.
174
+
There must also be a way to correlate a request with its response, this is usually handled with a header that the requester and responder agree on.
175
175
176
-
The library provides RPC client and server support classes.
176
+
The library provides requester and responder support classes.
177
177
They use sensible defaults and some of the internal mechanics are configurable.
178
-
They should meet the requirements of most RPC use cases.
179
-
It is still possible to implement one part or the other with regular publishers and consumers for special cases, as this is what the RPC support classes do.
178
+
They should meet the requirements of most request/response use cases.
179
+
It is still possible to implement one part or the other with regular publishers and consumers for special cases, as this is what the request/response support classes do.
The `RpcClient#publish(Message)` method returns a `CompletableFuture<Message>` that holds the reply message.
220
+
The `Requester#publish(Message)` method returns a `CompletableFuture<Message>` that holds the reply message.
221
221
It is then possible to wait for the reply asynchronously or synchronously.
222
222
223
-
The RPC server has the following behavior:
223
+
The responder has the following behavior:
224
224
225
225
* when receiving a message request, it calls the processing logic (handler), extracts the correlation ID, calls a reply post-processor if defined, and sends the reply message.
226
-
* if all these operations succeed, the server accepts the request message (settles it with the `ACCEPTED` outcome).
227
-
* if any of these operations throws an exception, the server discards the request message (the message is removed from the request queue and is https://www.rabbitmq.com/client-libraries/amqp-client-libraries#message-processing-result-outcome[dead-lettered] if configured).
226
+
* if all these operations succeed, the responder accepts the request message (settles it with the `ACCEPTED` outcome).
227
+
* if any of these operations throws an exception, the responder discards the request message (the message is removed from the request queue and is https://www.rabbitmq.com/client-libraries/amqp-client-libraries#message-processing-result-outcome[dead-lettered] if configured).
228
228
229
-
The RPC server uses the following defaults:
229
+
The responder uses the following defaults:
230
230
231
231
* it uses the _request_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`message-id` property] for the correlation ID.
232
232
* it assigns the correlation ID (so the _request_ `message-id` by default) to the _reply_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`correlation-id` property].
233
233
* it assigns the _request_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`reply-to` property] to the _reply_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`to` property] if it is defined.
234
-
This behavior is hardcoded but it is possible to cancel it thanks to a reply post-processor.
234
+
This behavior is hardcoded, but it is possible to override it thanks to a reply post-processor.
235
235
236
-
The RPC client uses the following defaults:
236
+
The requester uses the following defaults:
237
237
238
238
* it uses https://www.rabbitmq.com/docs/direct-reply-to[direct reply-to] if available (RabbitMQ 4.2 or more) for replies if no reply-to queue is set (it falls back to an auto-delete, exclusive queue if direct reply-to is not available)
239
239
* it uses a string-based correlation ID generator, with a fixed random UUID prefix and a strictly monotonic increasing sequence suffix (`{UUID}-{sequence}`, e.g. `6f839461-6b19-47e1-80b3-6be10d899d85-42`).
240
-
The prefix is different for each `RpcClient` instance and the suffix is incremented by one for each request.
240
+
The prefix is different for each `Requester` instance and the suffix is incremented by one for each request.
241
241
* it sets the _request_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`reply-to` property] to the reply-to queue address (defined by the user or created automatically, see above).
242
242
* it sets the _request_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`message-id` property] to the generated correlation ID.
243
243
* it extracts the correlation ID from the _reply_ https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties[`correlation-id` property] to correlate a reply with the appropriate request.
244
244
245
-
Let's see how to customize some of the RPC support mechanics.
245
+
Let's see how to customize some of the request/response support mechanics.
246
246
Imagine the request `message-id` property is a critical piece of information and we do not want to use it as the correlation ID.
247
-
The request can use the `correlation-id` property and the RPC server just has to extract the correlation ID from this property (instead of the `message-id` property by default).
247
+
The request can use the `correlation-id` property and the responder just has to extract the correlation ID from this property (instead of the `message-id` property by default).
248
248
Let's also use a random UUID for the correlation ID generation (avoids doing this in production: this is OK in terms of uniqueness but not optimal in terms of performance because randomness is not cheap).
0 commit comments