Here's a question... Do these named queues (work queues) co-exist distinctly on the RabbitMQ instance? In other words, can one MQ instance scale up to handle scenarios where subscribers can also become publishers and distribute their requests to 'n' other work queues and ultimately follow the callback chain back to the original publisher? I'm thinking the either the response could be chained back or the subscriber header could be returned as a list so that the publisher can listen to each callback queue individually.
I'm curious as to how this would perform. As someone who is new to RabitMQ and MQ in general i'm wondering if this is a capability that is possible from a RestBus standpoint or would this need to be executed via the traditional RabbitMQ API.
Yes, you can have multiple queues on the RabbitMQ instance and a server can also publish messages.
There isn't any performance issues with the scenario you described. The publisher will need to use two or more clients (one for each service) and instead of calling
await clientA.GetAsync()
it will call
var resA = clientA.GetAsync();
var resB = clientB.GetAsync();
...
var resAll = Task.WaitAll/Task.WaitAny(new Task[]{resA, resB});
Comments
This seems pretty neat.
Here's a question... Do these named queues (work queues) co-exist distinctly on the RabbitMQ instance? In other words, can one MQ instance scale up to handle scenarios where subscribers can also become publishers and distribute their requests to 'n' other work queues and ultimately follow the callback chain back to the original publisher? I'm thinking the either the response could be chained back or the subscriber header could be returned as a list so that the publisher can listen to each callback queue individually.
I'm curious as to how this would perform. As someone who is new to RabitMQ and MQ in general i'm wondering if this is a capability that is possible from a RestBus standpoint or would this need to be executed via the traditional RabbitMQ API.
Yes, you can have multiple queues on the RabbitMQ instance and a server can also publish messages.
There isn't any performance issues with the scenario you described. The publisher will need to use two or more clients (one for each service) and instead of calling
it will call to wait for all clients to complete.Documentation: https://github.com/tenor/RestBus/wiki
Benchmarks: https://github.com/tenor/RestBus.Benchmarks
Home page: http://restbus.org