Hello , We're using RabbitMq as distributed event bus and we're using eto's between different modules for communication. We have a case like => if one of the messages takes to much time to finish then rabbitmq puts that message into unacked side , because consumer didn't return any response (which is normal behaviour). This message is being executed by consumer (our apihost ) (btw the finishing time of that process is not crucial for us). But at the same time we're continuing to send different etos to rabbitmq , too. These 2nd or 3rd messages are kept in also as unacked (which is again normal behaviour). But we don't want to wait this first long-running process , for our small events . The other events shouldn't wait for this first long-running task. Because of that we saw prefetchCount option. When we change prefetchCount to 10 in rabbitmq configurations (default is 1 I guess in abp ) , nothing changed , still our other messages kept as unacked an wait for the first one. Then we read maybe we can create different channels for consumers and producers in same connection. But within abp we couldn't find a way to do that. Why prefetchCount isn't working, can we create different channels ? These approaches make sense to you to solve our issue ? What can be your suggestion on that point ?
Thank you.
Check the docs before asking a question: https://docs.abp.io/en/commercial/latest/ Check the samples to see the basic tasks: https://docs.abp.io/en/commercial/latest/samples/index The exact solution to your question may have been answered before, and please first use the search on the homepage. Provide us with the following info:
- ABP Framework version: v8.1.3
- UI Type: MVC
- Database System: EF Core (SQL Server)
- Tiered (for MVC) or Auth Server Separated (for Angular): yes
3 Answer(s)
-
0
See: https://www.rabbitmq.com/tutorials/tutorial-two-dotnet#fair-dispatch
The
prefetchCountis for multi-workers.You misunderstood the meaning of
prefetchCount.RabbitMQ pushes messages to the worker, but the worker processes them sequentially
-
0
Thank you , ok then in that case we couldn't change the behaviour , because we have one consumer. Maybe we can move this operation into background job (hangfire). What do you think about that approach ?
-
0
Hi selinkoykiran
I think the Hangfire is a good approach.
