NServiceBus 6.2 losing messages with RabbitMQ

383 Views Asked by At

I'm using NSB version6.2 and RabbitMQ version 4. I'm using RabbitMQTransport. My RabbitMQ server is in a virtual machine in Azure. when I send messages, sometimes I'm losing messages without any error.

this is my NService Bus configuration.

            EndpointConfiguration config = null;
        string endpointName = ConfigurationManager.AppSettings.Get("NServiceBus.EndpointName");
        config = configEndPoint.IsNullOrDefault() ? new EndpointConfiguration(endpointName) : configEndPoint;
        int maximumConcurrencyLevel = ConfigurationManager.AppSettings.Get("NServiceBus.TransportConfig.MaximumConcurrencyLevel").ToInt();
        config.LimitMessageProcessingConcurrencyTo(maximumConcurrencyLevel);
        int numberOfRetries = ConfigurationManager.AppSettings.Get("NServiceBus.TransportConfig.NumberOfRetries").ToInt();
        var recoverability = config.Recoverability();
        recoverability.Immediate(
            customizations: immediate =>
            {
                immediate.NumberOfRetries(numberOfRetries);
            });

        DefaultFactory defaultFactory = LogManager.Use<DefaultFactory>();
        defaultFactory.Directory(this.DatabusDirectory);
        defaultFactory.Level(LogLevel.Error);

        config.IdealinkJsonSerializer();
        config.UsePersistence<InMemoryPersistence>();

        config.SendFailedMessagesTo("error");
        config.AuditProcessedMessagesTo("audit");

        // configure transport
        config.UseTransport<RabbitMQTransport>().Transactions(TransportTransactionMode.ReceiveOnly);
         var endpointInstance = Endpoint.Start(endpointConfiguration).GetAwaiter().GetResult();
1

There are 1 best solutions below

2
On

Configuration of your endpoint looks fine with an exception of persistence. Persistence is used for features that are not supported by the underlying transport natively. For RabbitMQ, there is not native mechanism to send delayed messages. Until version 4.3 persistence was used to store timeouts. If you use InMemoryPersistence, none of the information will be retained after endpoint restarts. Timeouts are needed for Recoverability feature, specifically delayed retries. From version 4.3 and above, persistence is not required for timeouts, but InMemoryPersistence should still not be used. You can chose other persistences based on technology and scenario at hand.

Please note that version 4.0.0 is not under supported versions. You should update to 4.3.x or 4.4.x and verify the behavior to see if you notice a message loss or not. In case you still losing messages, I suggest providing more details such as log file and handler code. If you can't share that publicly, submit a support case.

Hope that helps.