2014-09-28 5 views
3

Мы используем NServiceBus на производстве, так и в наших файлах журнала мы видим следующее сообщение об ошибке:NServiceBus - сообщение не всегда доставляет и вызывая исключение может зачислить по сделке

ERROR Our.Namespace.SomeMessageHandler [(null)] <(null)> - MethodName --> end with exception: NServiceBus.Unicast.Queuing.FailedToSendMessageException: Failed to send message to address: [email protected] ---> System.Messaging.MessageQueueException: Cannot enlist the transaction. 
    at System.Messaging.MessageQueue.SendInternal(Object obj, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType) 
    at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.NServiceBus.Unicast.Queuing.ISendMessages.Send(TransportMessage message, Address address) 
    --- End of inner exception stack trace --- 
    at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.ThrowFailedToSendException(Address address, Exception ex) 
    at NServiceBus.Unicast.Queuing.Msmq.MsmqMessageSender.NServiceBus.Unicast.Queuing.ISendMessages.Send(TransportMessage message, Address address) 
    at NServiceBus.Unicast.UnicastBus.SendMessage(List`1 addresses, String correlationId, MessageIntentEnum messageIntent, Object[] messages) 
    at NServiceBus.Unicast.UnicastBus.SendMessage(Address address, String correlationId, MessageIntentEnum messageIntent, Object[] messages) 
    at NServiceBus.Unicast.UnicastBus.NServiceBus.IBus.Send(Address address, Object[] messages) 
    at Our.Namespace.SomeMessageHandler.MethodName(EventLogVO eventLog, IApplicationContext applContext, CreateEventLogHistory message) 

Очередь на целевой машине существует (двойной проверено). Странная вещь здесь заключается в том, что она не происходит все время и для каждого сообщения, отправленного в эту очередь, но иногда происходит (что означает, что есть сообщения, которые поступают в эту очередь).

Искал и не нашел аналогичный случай.

Что мне здесь не хватает?

+0

Основываясь на вашем другом вопросе, я предполагаю, что ваша транзакция - это тайм-аут. Если нет, я рекомендую вам показать код и описать, что делают сообщения, которые не работают. –

ответ

3

Недавно мы имели эту ошибку и отслеживали его вниз, чтобы быть одним из следующих:

  • производительности базы данных. У нас был длинный запрос, который мы настроили, но проблема сохранилась.
  • Большой объем транзакций. Вы можете делать что-то, что может вызвать слишком много менеджеров ресурсов.
  • Ресурсы MSMQ. В конечном итоге наш диск был недостаточно быстрым, чтобы выполнить IO, требуемое для того, что мы делали с MSMQ.

Я бы попытался отследить истинный источник (надеюсь, вы получите некоторые идеи сверху). Но если все остальное не удается, сначала включите ведение журнала System.Transactions, чтобы узнать, действительно ли это тайм-аут. Если это так, то используйте this section в app.config

+0

+1 над превышением квоты MSMQ (возможно, вы захотите его инкриминировать), также проверьте свою транзакционную мертвую буквенную очередь и очистите ее –

1

У меня было это случилось со мной в обработчике, который взял на минуту, чтобы закончить, я в конечном итоге увеличить время ожидания, добавив в файл app.config

<system.transactions> 
    <defaultSettings timeout="00:05:00"/> 
</system.transactions> 

в соответствии с этим: https://erictummers.wordpress.com/2014/05/28/cannot-enlist-the-transaction/

Кроме того, я изменил машину конфигурации, как на этот пост: http://blogs.msdn.com/b/ajit/archive/2008/06/18/override-the-system-transactions-default-timeout-of-10-minutes-in-the-code.aspx

Я также написал быстрое приложение, которое редактирует файл machine.configs: https://github.com/hfortegcmlp/MachineConfigEditor