In order processing is very difficult (I would say impossible) so generally a bad idea. I don't know exactly what your requirements are but perhaps you could use a saga? (https://masstransit-project.com/MassTransit/usage/sagas/)
since I assume that the reason you're worried about them processing in order is because something is supposed to happen afterwards?
@darthkurak Multiple instances with the same subscription work as competing consumers so you won't get duplicated messages, but you can't guarantee the order of messages, if you want to make sure messages are processed in order you'd have to implement some sort of mechanism to do so. Saga as suggested earlier could do in certain scenarios. If in your system events out of order are fairly rare you could implement fairly simple version check and just throw exception on message out of order and use retry mechanism to try after certain delay, this method won't work very well if you deal with high volumes of messages.
Also there is certain functionality in service bus which can almost guarantee message ordering - Message sessions but it got significant draw backs and it's not very feasible to use with MT, We had one service using message sessions then we introduced MT to our services but the session based stuff had to be implemented using plain ASB API. Personally I wouldn't recommend it but it's one of the options.
https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-sessions
Also there is certain functionality in service bus which can almost guarantee message ordering - Message sessions but it got significant draw backs and it's not very feasible to use with MT, We had one service using message sessions then we introduced MT to our services but the session based stuff had to be implemented using plain ASB API. Personally I wouldn't recommend it but it's one of the options.
https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-sessions
Thanks for responses. What we want to achieve is mechanism between Microservices to sync data if required. Each Microservices can subscribe to events of other Microservices and do something with them. It can be some calculations, other time - updating domain model with information from other service and so on. Assuming incorrect order, this may end up with some bugs. Example - micro service A publish two events when company is created - one CompanyCreated, second - CompanyRelationsWasSet . This two events will be published almost at the same time. Micro service b subscribe to topic “company” and want process this events for its own purpose. Let’s assume that it will create Company object within its own database - if this events will be processed in not order - CompanyRelationsWasSet will fail because company object doesn’t exist, yet. Saga seems to be overkill for such simple case. Events I want always to be processed in order. I know the service bus sessions but this exclude usage of massTransit. I thought this is common case- but apparently seems to be not - how then, you model sync mechanism based on pub sub between services where you don’t want bother about the logic case by case - just have processing in order? For me this seems like something obvious to have - but maybe my reasoning is wrong. How to model pub sub communication between Microservices without not having the order?
MT is definitely not an ES solution but it could be part of one
Question, I'm having some strange (new) behaviour with EntityFrameworkSagaRepository and dbcontext messes, so I'm looking at my bindings. Is EntityFrameworkSagaRepository supposed to be registered singleton? Seems like it, but if I feed it a custom DbContextFactory I realised that the lifetime scope that gets injected there will be a one-off. Not clear to me whether we need a fresh lifetime scope
or u can register
ISagaRepository<TSaga> with EntityFrameworkSagaRepository.CreateOptimistic/Pessimistic(sp.GetService<Context>)
@nizmow Take a look at the registration here: https://github.com/MassTransit/Sample-Batch/blob/master/src/SampleBatch.Service/Program.cs
that will create a DbContext scoped on the Saga Consume
I always prefer to use the SagaScopedDbContext rather than the built in DelegateSagaDbContextFactory
@ellepitre the upgrade notes are here: https://masstransit-project.com/getting-started/upgrade-v6.html
@Alksar you can specify that the bus endpoint is not AutoStart(ed), and you can still override the name.
builder.AddMassTransit(cfg =>
{
cfg.AddMongoDbSagaRepository<TSaga>(...);
// or maybe better...
cfg.AddSaga<TSaga>(...)
.WithMongoDb(...);
});
I can figure out the wiring under the hood so that the proper interfaces are setup in the container, but it sure would make it easier imho.
my phone sends message without me :) I’m thinking we are at the same wave, I was thinking. about extensions to help users to register repo easily, right now you have to keep in mind so much...
I face couple ideas about that))
have couple ideas *
@phatboyg Any tips/tricks around configuring Masstransit within a AspNetCore 2.2 app that is using LAMAR? Should we bring in all of the following nugets?
Lamar 3.2.0
Lamar.Microsoft.DependencyInjection 3.2.0
MassTransit 5.5.5
MassTransit.AspNetCore 5.5.5
MassTransit.Lamar 5.5.5
MassTransit.Extensions.Logging 5.5.5
MassTransit.RabbitMQ 5.5.5
Lamar 3.2.0
Lamar.Microsoft.DependencyInjection 3.2.0
MassTransit 5.5.5
MassTransit.AspNetCore 5.5.5
MassTransit.Lamar 5.5.5
MassTransit.Extensions.Logging 5.5.5
MassTransit.RabbitMQ 5.5.5
@seantmcdermott_gitlab that looks right, you can check: https://masstransit-project.com/usage/containers/lamar.html
I try through serilog to send logs to rabbitmq and get them in another service via masstransit
@Obey177 check out https://masstransit-project.com/architecture/interoperability.html for message format.
Hey all. I have application that uses microservice architecture. I have 5 services that communicate using amqp over rabbitmq over masstranist.
I do have a fair number of request/response calls configured. When under load I am frequently seeing:
MassTransit.Messages Error: 0 : R-FAULT rabbitmq://rabbitmq:5671/MyQuename?durable=false cd460000-50cb-b253-4da2-08d77982802c
...(00:00:41.7920601) rabbitmq://rabbitmq:5671/some_service7887756876jqx8p_dotnet_bus_3idyyyno3q3fghqubdmzg47ynk => The message was not confirmed: PRECONDITION_FAILED - invalid expiration '-26069': {value_negative,-26069}, MassTransit.RabbitMqTransport.MessageNotConfirmedException: rabbitmq://rabbitmq:5671/some_service7887756876jqx8p_dotnet_bus_3idyyyno3q3fghqubdmzg47ynk => The message was not confirmed: PRECONDITION_FAILED - invalid expiration '-26069': {value_negative,-26069}I know that the dotnet_bus queues are temporary queues MT creates to enable request/response. I know those queues have an expiry of 60 seconds. What I'm inferring from this error message is a message was unable to be confimed because the ttl has been exceeded. I am seeing some failures in the application that COULD(I'm not sure yet) be attributed to dropped messages. When I look at the queues in rabbitmq via rabbitmqctl list_queues I'm not seeing queues that appear backed up. I'm wondering if anyone could tell me what the above error could imply. Would this indeed result in dropped messages?