MassTransit handles sending commands by using user-defined queue names on the ReceiveEndpoints. If there are four load-balanced servers running a consumer for a specific message type, when you send a command to that consumer, you don’t want it picked up by all four consumers at once, you want the first available consumer to receive the message and process it, while the other three stay idle listening for other messages. This is why the competing consumers pattern is essential for commands. These type of actions should only happen once, even in a load-balanced environment. Commands are actions like CreateEntity, UpdateEntity, DeleteEntity, etc. Handler( context => ) Ĭommands are messages that directed at a single consumer, no matter how many different ones are listening for that message type. ReceiveEndpoint( host, "queue_name ", endpoint =>Įndpoint. ReceiveEndpoint with queue name (Competing Consumer) var bus = Bus. This is key to supporting or bypassing the competing consumer pattern, as you will see later on. When creating a receive endpoint, you can either specify a unique queue name or have one auto generated for you. Setupīefore you can send or publish messages in MassTransit, you need to configure the ReceiveEndpoints and attach handlers/consumers to them. Now lets take a look at how MassTransit supports these different methods of communication and why you might want each type. Publishing a message (Event) to all consumers who are subscribed to that message type without using the “Competing Consumer” pattern.Publishing a message (Event) to all consumers who are subscribed to that message type using the “Competing Consumer” pattern.Sending a message (Command) directly to a specific consumer who is subscribed to that message type using the “ Competing Consumer” pattern.There are three main ways that you might want to send messages when using a message bus for asynchronous communication between systems in a distributed environment.
0 Comments
Leave a Reply. |