Masstransit: "Sending messages" documentation

[alexeyzimarev]

Could you guys spend a couple of minutes and briefly write about sending messages versus publishing messages:

http://docs.masstransit-project.com/en/latest/overview/sending.html

I am sure the community can take it forward but we need a starting point.

[adminnz]

Still waiting on this.. there are multiple scenarios where systems need to send directly to a queue rather than going via the whole Publish -> Topic -> Binding(s) -> Queue -> Consumer

[alexeyzimarev]

@adminnz You can use Send, this is not a problem. I asked to have it documented in a proper way so people know how is it different from publishing. There is a good overview here but it would be nice to have it in the docs.

[waynebrantley]

If you 'send' a message then only one queue subscriber will ever see it.
If you 'publish' a message then anyone can build something that listens for that and see it.

We do not use any send messages. It locks us in. For instance if we want to use a 'UpdateCustomer' message as a send...then later you want something else to listen and act on that same 'UpdateCustomer' message - you cannot do it.

Some people use 'send' as commands and 'publish' as events. So, in the above, they would create an UpdateCustomer message and 'send' it. When finished processing, it would publish a 'CustomerUpdated' message that anyone can listen to.

My issue with that is you are not going to over-engineer your solution and publish all kinds of messages 'just in case' someone needs to know about it later. So, you build the above and do not create the CustomerUpdated message. Later when someone else needs it, you have to modify the consumer of UpdateCustomer to send the CustomerUpdated message. If you just publish only, you could have gotten it without any other consumer or processing knowing or being modified.

However, from what I can tell, I am in the minority. :-)

[alexeyzimarev]

I think clear separation between commands and events is very important. When you send UpdateCustomer and have "someone else" listening to it, it can start doing something with an assumption that the operation has happened. But there is no single guarantee that it has actually been done. The processing service might be down. There might be an error when updating the customer. But your follow up process does things anyway. This is clearly very dangerous.

Also, when you "publish" commands, there is no need for anyone to listen to it. When there is no subscriber, it will just disappear. When you "send" and there is no queue, it will fail, which is good.

[waynebrantley]

Valid points, but I don't really use it for things like 'update customer', so perhaps I just use it more for event things. However, an 'event' can be consumed and used just like a 'command'. However, a command cannot be used and consumed just like an event. So, the most flexibility is in publishing things.

I would have much bigger issues if I had missing queues. :-)

[TravisTheTechie]

It says "Coming Soon" and that page hasn't been updated since last year, so I'm going to call that a lie. We should update this.

[adminnz]

@alexeyzimarev The GetSendEndpoint(uri) and corrisponding Send(..) do not allow you to send directly to a queue.
For instance if you run just the website in the sample project, from the blog post you linked.
It will end up creating a "my_commands" exchange and a "StarterKit.Contracts:MyEvent" exchange.

There is no way to send directly to a queue. Yes you can send to an exchange that might at some future time eventually have a consumer started that will setup bindings. But until then, all the messages you send are just going to get dropped.

Masstransit should at least expose a method to send directly to a queue. Something like:
var endpoint = bus.GetEndpoint(queue); endpoint.Send<MyCommand>(new { Message = "Hi"});

[phatboyg]

http://docs.masstransit-project.com/en/latest/usage/producing.html

[dasiths]

@adminnz With Send->Receive pattern it would be expected MassTransit to handle it. It's not like a Publish where we don't care about if anyone is listening. A Command needs to wait in the queue until a consumer picks it up. That's how EasyNetQ does it.

[alexeyzimarev]

@dasiths this is how MassTransit works.

[riezebosch]

I have observed the following behaviour.

The consumer for my command is never initialized before, so there is no queue (yet). When I send the message to the endpoint this consumer will eventually be listening to my message gets lost.

That makes no sense to me. I understand that the sender doesn't know the details of the queue being initialized but I really would expect it be stored in some sort of queue on the producers site or to fail on that site at least.

I have a working repro in a test that I will attach later.

[alexeyzimarev]

Well, I am not sure why would you send a message for a non-existing consumer and expect it to get somewhere?

[riezebosch]

Building and deploying a producer and consumer in parallel (by distinct teams) where the producing side could be ahead of the consuming side.

After poking in the rabbitmq docs I could imagine something like this to be used:

To ensure messages are routed to a single known queue, the producer can just declare a destination queue and publish directly to it. If messages may be routed in more complex ways but the producer still needs to know if they reached at least one queue, it can set the mandatory flag on a basic.publish, ensuring that a basic.return (containing a reply code and some textual explanation) will be sent back to the client if no queues were appropriately bound.

[asheeshv]

I had a question regarding the type of message send using the Publish API. I know the queues created by Publish are durable, but are the messageTypes sent through Publish method persistent by default as well? I didn't see any API where in I can specify inside the Publish method that the delivery type is Persistent. Would this mean any message sent through the Publish API is persistent? Thanks!

[alexeyzimarev]

Publish does not create queues. To publish messages we need exchanges.
Queues are created by consumers. Everything is by default durable.

On Tue, 11 Sep 2018 at 21:30, Asheesh Vashishtha [e-mail]
wrote:

I had a question regarding the type of message send using the Publish API.
I know the queues created by Publish are durable, but are the messageTypes
sent through Publish method persistent by default as well? I didn't see any
API where in I can specify inside the Publish method that the delivery type
is Persistent. Would this mean any message sent through the Publish API is
persistent? Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MassTransit/MassTransit/issues/521#issuecomment-420414659,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACsMVaRZgAVfVNtWnUOmIur2N4RCGiO5ks5uaB1cgaJpZM4H0-Bu
.

>

Med vennligst hilsen / Best regards,
Alexey V. Zimarev

[dasiths]

@alexeyzimarev Can you confirm the following. With the send/receive pattern, does it create a queue for the message types when we send (Then the consumer just subscribes to the queue)? Or does the registration of the consumer (upon startup) create the queue and exchange binding?

[phatboyg]

Send does not create the queue, it will on RabbitMQ create the exchange. The receive endpoint with the consumer creates the binding from the exchange to the queue, along with the queue itself.

There are parameters you can add to the endpoint address, I think it's bind=true to force the sender to create/bind the exchange to the queue.