Currently, the bus queue is always created. Consider creating this on-demand when needed by the request client, and make it an option to specify that they aren't created.
I'm not sure what side effects this will cause, but enough people ask about it so consider it an opportunity to reduce the queue count on the broker.
Hello, this feature would be very useful to me, is there an update on this effort?
Thank you
Just read on aws whats-new blog there is first class support for temporary queues, https://aws.amazon.com/about-aws/whats-new/2019/07/temporary-queue-client-now-available-for-amazon-sqs/ will have a look if this might be something we could use in the amazon sqs transport related to #1389
Add a receive endpoint configuration flag so that a receive endpoint can opt-out of being started automatically. When a consumer connects to the receive endpoint, it would then start - which may include asking for the receive endpoint's address in the case of it being generated as a temporary queue name.
This would allow the bus endpoint to remain stopped until a request client or something connected a consumer to it. Or until a send/publish using the IBus's IPublishEndpoint was initiated, since it would ask for the input address as the SourceAddress.
(these notes are for me, so that I can actually do it on the v6 branch later)
Hello! i created temporary queue:
"ConnectHandle handle = busControl.ConnectConsumer
then i publish "MyMessage"
why consumer not getting message?
Because the bus endpoint doesn’t bind or subscribe consumers. It’s meant to be used for responses and other messages sent directly to the queue.
Thank! Understood!
On Thu, Jun 4, 2020 at 2:56 PM Chris Patterson notifications@github.com
wrote:
Because the bus endpoint doesn’t bind or subscribe consumers. It’s meant
to be used for responses and other messages sent directly to the queue.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MassTransit/MassTransit/issues/1390#issuecomment-638801785,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN3TYXS5GSL22FOTJGYMHJDRU6DV3ANCNFSM4HARZT3Q
.
Most helpful comment
Just read on aws whats-new blog there is first class support for temporary queues, https://aws.amazon.com/about-aws/whats-new/2019/07/temporary-queue-client-now-available-for-amazon-sqs/ will have a look if this might be something we could use in the amazon sqs transport related to #1389