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
Copy file name to clipboardExpand all lines: README.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -390,6 +390,7 @@ rpc_clients:
390
390
connection: default #default: default
391
391
unserializer: json_decode #default: unserialize
392
392
lazy: true #default: false
393
+
direct_reply_to: false
393
394
rpc_servers:
394
395
random_int:
395
396
connection: default
@@ -490,6 +491,12 @@ public function indexAction($name)
490
491
491
492
Is very similar to the previous example, we just have an extra `addRequest` call. Also we provide meaningful request identifiers so later will be easier for us to find the reply we want in the __$replies__ array.
492
493
494
+
### Direct Reply-To clients ###
495
+
496
+
To enable [direct reply-to clients](https://www.rabbitmq.com/direct-reply-to.html) you just have to enable option __direct_reply_to__ on the __rpc_clients__ configuration for the client.
497
+
498
+
This option will use pseudo-queue __amq.rabbitmq.reply-to__ when doing RPC calls. On the RPC server there is no modification needed.
499
+
493
500
### Multiple Consumers ###
494
501
495
502
It's a good practice to have a lot of queues for logic separation. With a simple consumer you will have to create one worker (consumer) per queue and it can be hard to manage when dealing
0 commit comments