Sending messages

[Alex Wheat]

Hi

we just recently started to research MassTransit capabilities and not everything is clear yet... One of the questions that I currently have, why do we need to specify queue name when send a command? In other words, why should we GetSendEndpoint and only after that send a command to that specific end point? Why we can't just sens a command to the bus and MT do the rest of the job?

sorry, if this question already been answered... couldn't find anything related

Regards,
Alex

[Dru Sellers]

Hello,

If you don’t specify the destination endpoint, then you are doing a Publish and letting MT route the message. When doing a command, you want it to go to a specific service. You could have command processors that handle different clients for instance. So, you may want to choose the command handler based on the any number of issues, once you’ve selected one you can then dispatch it.

When I publish a message I just yell it as loud as I can “Fire!” for instance. I expect anyone that cares about fires to react accordingly, but its a fire and forget kinda thing.

If I tell someone to “Close the door”, I’m picking someone to tell. I’m not just shouting “Close the Door!” and _hoping_ someone does.

Does that help?

-d

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d1b37686-2bee-4df0-bfc4-2d79eeeb45a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Zimarev]

It is actually described here http://masstransit-project.com/MassTransit/usage/producing-messages.html

[Alexey Zimarev]

There's also work done and being done to implement message contract to endpoint address mapping using configuration. So when you have configured the endpoint to message mapping, sending a message that has such configuration, would automatically route to the correct endpoint. The feature is not yet complete and therefore not documented. What you can use now (I suppose) is:

EndpointConvention.Map<MyMessage>(new Uri("rabbitmq://localhost/vh/my-service-queue"));

once, and then somewhere

await context.Send(new MyMessageImpl("here we go"));

But in essence as Dru wrote:

When you Send - you must know where, you have the intention for something to be done. 

If you Publish - you don't really expect someone to listen, your job is to inform.

On Wednesday, 18 January 2017 18:03:20 UTC+1, Alex Wheat wrote:

[Alex Wheat]

Hi,
thanks for the responses and explanations! Appreciate it!

Actually, when I asked the question I tried to figure out why I should care about the queue name in order to sent some command and why this process cannot be automated. For example, next couple very simple extensions would simplify my life, so we don't have to worry about configuring proper queue names

    public static class ISendEndpointProviderExtensions
    {
        public static async Task SendCommand<T>(this ISendEndpointProvider endpointProvider, object message) where T : class
        {
            var queueUri = $"{ConfigurationManager.AppSettings["rabbitmq:host"].TrimEnd('/')}/commands-{typeof(T).FullName}";
            var sendEndpoint = await endpointProvider.GetSendEndpoint(new Uri(queueUri));

            await sendEndpoint.Send<T>(message);
        }
    }

    public static class IRabbitMqBusFactoryConfiguratorExtensions
    {
        public static void ReceiveCommand<T>(this IRabbitMqBusFactoryConfigurator configurator, IRabbitMqHost host, Action<IRabbitMqReceiveEndpointConfigurator> configureEndpoint)
        {
            configurator.ReceiveEndpoint(host, $"commands-{typeof(T).FullName}", configureEndpoint);
        }
    }

so, first one is used to send a command like this

    await _bus.SendCommand<MyCommand>(new
    {
         Message = string.Format("Command{0}", i)
    });

and the second one is used to receive the command

    sbc.ReceiveCommand<MyCommand>(host, e =>
    {
          e.LoadFrom(componentContext.Resolve<ILifetimeScope>());
    });

Is it a good or bad idea to operate with MassTransit this way? And if it's bad, why?

Regards,

Alex

--
You received this message because you are subscribed to a topic in the Google Groups "masstransit-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/masstransit-discuss/ur0PcHKJ5_g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstransit-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/2e1b0fdb-f312-4c2f-b382-4aa1c5555320%40googlegroups.com.

[Alexey Zimarev]

Well, your extensions are very opinionated. Nobody can stop you from implementing them.

There are a couple of points that I can mention about your code:

1. Whilst your SendCommand actually does what it says - sends a command, the ReceiveCommand just configures an endpoint. A bit of confusing naming.
2. You can do the configuration now even easier using conventions, like I mentioned before. The example I wrote should work just fine. You statically configure it once and it will work.
3. The receiving part configures an endpoint with own queue per command type but you load all registered consumers, isn't that strange?
4. There is no need to use queue/endpoint per message type, one endpoint can serve as many message types you want. This is more like personal taste.

[Chris Patterson]

But you should separate endpoints by business concern, and recognize that messages on the same endpoint will compete for each other. A lower frequency but higher importance message could get behind a bunch of higher frequency messages that are not important.

More queues = more scale = more separation = less bottlenecks.

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstransit-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/4297a332-1df1-4734-9084-9b93ec407f23%40googlegroups.com.

[Alexey Zimarev]

> you should separate endpoints by business concern

No doubt. We usually have service per bounded context. Sometimes several services but those have different queues due to scaling requirements (below)

> A lower frequency but higher importance message could get behind a bunch of higher frequency messages that are not important.

Yeah, we usually split services that have different scaling requirements.